mysql: Neue Frage im alten Thema zur Vermeidung eines Doppelpost

[dedlfix]

Tach!

Die ID ist normalerweise kein Sortierkriterium, weil die nicht garantiert aufsteigend vergeben wird. Die solltest du üblicherweise aus solchen Neuer-Älter-Betrachtungen herauslassen.
Auch als autoincremment-Wert nicht?

Nun, Theorie und Praxis. Theoretisch kann der Wert überlaufen und dann fängt er wieder unten an. Theoretisch dürftest du auch keinerlei Garantie finden, dass auto_increment immer aufsteigend vergibt. Praktisch mag das zutreffen. Praktisch sind auch Regelübertretungen (wenn man das obige mal als Regel ansieht) problemlos möglich, solange man mit den Konsequenzen leben kann oder sie als gering einschätzt. Ich selbst versucht, die ID-Verwendung für solche Zwecke zu vermeiden, aber bevor ich in Schönheit sterbe, muss manchmal doch die ID als (zusätzliches) Sortierkriterium herhalten.

Denn dann werde ich die DB ein klein wenig umstrukturieren. Ich weiß noch nicht ganz genau, wie ich das mache, aber es gäbe einige Möglichkeiten. Ich könnte z.b. anstelle eines INSERTS ein Update nutzen. Damit hätte ich augenblicklich keine "doppelten" Datensätze mehr.

INSERT ... ON DUPLICATE KEY UPDATE ... wäre da vielleicht ein Kandidat.

Nachteil wäre, daß ich die Historie des Datensatzes verlieren würde. Aber das könnte ich anders regeln, zb. über 2 Tabellen. 1 Tabelle für den aktuellen Stand, die 2. Tabelle für die "historischen" Stände.

Oder ein Flag aktuell/veraltet. Das würde dann aber zwei Abfragen beim Hinzufügen bedeuten. Erstmal alle Datensätze desselben Kriteriums auf veraltet setzen, dann den neuen einfügen. Und damit bist du dann bei Transaktionen angekommen, wenn dieser Vorgang auch bei Fehlern nicht nur teilausgeführt zurückbleiben soll. Eine Transaktion braucht es aber auch für die Wegspeichern-Methode, wenn sie teilausführungsunanfällig sein soll.

Das würde beim Eintragen etwas mehr Arbeit bedeuten, aber das Auslesen der Datensätze würde erheblich vereinfacht. Und da ich bei diesem Programmteil noch in den Anfängen stecke, ist es problemlos möglich, noch an der DB-Strucktur zu feilen.

Wenn das Schreiben sehr schnell gehen muss (zum Beispiel bei hoher Ereignisanzahl pro Zeiteinheit), dann wäre eher der Schreibvorgang optimierwürdig. Das Auslesen kann man dann auch mit einem mehrschrittigen Programm statt mit einer mit Bauch- und Kopfschmerzen zusammengeschraubten Einzelquery erledigen. Auch eine Stored Procedure wäre dazu geeignet. Aber wenn sich die Eintragungen in Grenzen halten, dann doch lieber die Duplikatsvermeidungsmethoden.

dedlfix.