Firebird Datensatz verschieben via PrimaryKey

[mkinzler]

Ich würde den Primärindex niemals ändern, sondern die Sortierungreihenfolge in einer eigene Spalte/Tabelle abbilden

[Perlsau]

Zitat von mkinzler:

Ich würde den Primärindex niemals ändern, sondern die Sortierungreihenfolge in einer eigene Spalte/Tabelle abbilden

Das wäre natürlich auch eine Möglichkeit: eine weitere Spalte anlegen, die die Reihenfolge enthält. Doch prinzipiell hätte ich hier dasselbe Problem, dessen Lösung mir gerade im Moment einfällt: Natürlich bleibt die physikalische Sortierung meiner Datenmenge im Dataset bestehen, so lange ich danach nicht frisch sortiere ... werd' ich gleich mal ausprobieren ... WOW, das war's auch schon. Manchmal hilft schon ein bißchen Reden darüber ...

Ich hatte oben vergessen zu erwähnen, daß vor dem Verschieben eine Sortierung nach PrimaryKey aufwärts erfolgt.

Eine Gefahr beim Ändern des PrimaryKey sehe ich hier eigentlich nicht, da ja nur Keys verwendet werden, die bereits existieren, von dem Key mit dem Wert 0 einmal abgesehen, der als Zwischenspeicher fungiert ...

Aber grundsätzlich hast du natürlich vollkommen recht, man sollte normalerweise nicht an den PrimaryKeys rumpfuschen ...

[Nersgatt]

Ich würde anders vorgehen.
wie mkinzler schon sagte: eigene Spalte für die Sortierung verwenden. Nicht den Primärindex. Index auf die Sortierspalte setzen.

Nach ganz oben Schieben:

Code:

Primärindex des zu verschiebenden Feldes merken
Für alle Datensätze, wo Sortierindex < AktuellerSortierindex:
  Sortierindex := Sortierindex + 1
Sortierindex des gemerkten Datensatz := 1

Nach ganz unten Schieben:

Code:

Primärindex des zu verschiebenden Feldes merken
Für alle Datensätze, wo Sortierindex > AktuellerSortierindex:
  Sortierindex := Sortierindex - 1
Sortierindex des gemerkten Datensatz := größter Sortierindex + 1

[mquadrat]

Völlig OT: Den Kommentarstil über den Methoden hab ich zuletzt bei Clipper gesehen Good ol' times

[Perlsau]

Zitat von mquadrat:

Völlig OT: Den Kommentarstil über den Methoden hab ich zuletzt bei Clipper gesehen Good ol' times

Hatte ich mir damals beim Erlernen von TurboPascal so angewöhnt und find das auch weiterhin sehr ansprechend und übersichtlich. Auch andere Programmierer, mit denen ich zusammengearbeitet habe, hatten sich über meinen Formatierungsstil stets gefreut und ihn teilweise sogar übernommen ... Zumindest kann ich meine Codes von vor Jahren noch immer gut und schnell erfassen ...

[Perlsau]

Zitat von Nersgatt:

Ich würde anders vorgehen.
wie mkinzler schon sagte: eigene Spalte für die Sortierung verwenden. Nicht den Primärindex. Index auf die Sortierspalte setzen

Naja, wie ich oben schon bemerkte, kann ich hier keine Gefahren durch das Ändern der PrimaryKeys entdecken. Aber ich werde mein Projekt jetzt erstmal sichern (auf Backupplatte kopieren) und dann mal mit der zusätzlichen Spalte ausprobieren. Könnte mir sogar vorstellen, daß das schneller ist als die Version mit den PrimaryKeys ... Danke für deinen Beitrag.

[Nersgatt]

Zitat von Perlsau:

Zitat von Nersgatt:

Ich würde anders vorgehen.
wie mkinzler schon sagte: eigene Spalte für die Sortierung verwenden. Nicht den Primärindex. Index auf die Sortierspalte setzen

Naja, wie ich oben schon bemerkte, kann ich hier keine Gefahren durch das Ändern der PrimaryKeys entdecken.

Iiiirgendwann wirst Du Dein Projekt erweitern. Dann wirst Du an einer ganz anderen Stelle im Programm diesen Primärindex in einer anderen Tabelle als Fremdschlüssel speichern. Und du wirst nicht mehr dran denken, die Sortierroutinen anzupassen. Und der Kunde wird Dich durch das Telefon ziehen, weil die Daten "auf einmal" völlig durcheinander sind. Und dann wirst Du einen halben Tag drauf verwenden, rauszufinden, wie das sein kann. Bis Du irgendwann auf die Sortierroutine stößt und mit der Stirn auf die Schreibtischplatte aufschlägst...

[Perlsau]

Zitat von Nersgatt:

Iiiirgendwann wirst Du Dein Projekt erweitern. Dann wirst Du an einer ganz anderen Stelle im Programm diesen Primärindex in einer anderen Tabelle als Fremdschlüssel speichern. Und du wirst nicht mehr dran denken, die Sortierroutinen anzupassen. Und der Kunde wird Dich durch das Telefon ziehen, weil die Daten "auf einmal" völlig durcheinander sind. Und dann wirst Du einen halben Tag drauf verwenden, rauszufinden, wie das sein kann. Bis Du irgendwann auf die Sortierroutine stößt und mit der Stirn auf die Schreibtischplatte aufschlägst...

Wie ich bereits erwähnte: Grundsätzlich stimme ich euch beiden (MKinzler & Nersgatt) vollkommen zu. Doch hier besteht die Gefahr tatsächlich nicht, weil eine Erweiterung, die die Wiederverwendung des Primärschlüssels in einer anderen Tabelle erfordert, nicht anstehen wird. Dennoch werde ich jetzt gleich im Anschluß deinen Vorschlag umsetzen, schon allein deshalb, weil ich sehen möchte, ob die Sortierung nach gewünschter Reihenfolge damit schneller läuft. Aber auch eine weitere Idee unterstützt deinen Vorschlag: ich möchte dem Anwender die Möglichkeit geben, den zu druckenden Seiten eine Seitennummerierung zu verpassen, wenn die eingescannten Bilder nicht bereits Seitenzahlen enthalten. Schließlich soll man damit nicht nur Buchseiten archivieren und ausdrucken können, sondern auch andere Bilder und Grafiken, Fotos usw. Daher heißt die neue Spalte nun SEITENNR.

Was ist eigentlich mit deiner I-Taste los?

[Nersgatt]

Hab mir gerade mal Deinen ersten Post nochmal angeschaut. So bombadierst Du natürlich die Datenbank mit UPDATEs. Je nachdem, wie viele Datensätze Du drin hast.

Bild nach oben schieben:

Code:

UPDATE BILDER SET SEITENR = SEITENR + 1 WHERE SEITENR < (SELECT SEITENR FROM BILDER WHERE IDX_BILDER = :IDX);
UPDATE BILDER SET SEITENR = 1 WHERE IDX_BILDER = :IDX;

Bild nach unten schieben:

Code:

UPDATE BILDER SET SEITENR = SEITENR - 1 WHERE SEITENR > (SELECT SEITENR FROM BILDER WHERE IDX_BILDER = :IDX);
UPDATE BILDER SET SEITENR = (SELECT COALESCE(MAX(SEITENR), 0) FROM BILDER WHERE IDX_BILDER = :IDX) + 1 WHERE IDX_BILDER = :IDX;

Parmeter IDX = zu verschiebender Datensatz

Ungetestet. So funktioniert das nur, wenn Du Index und Sortierfeld trennst. Denn nach dem ersten Update beim Nach-Oben-Schieben hast Du 2 Datensätze mit der selben Seitennummer. Das wird beim 2. Update sofort wieder korrigiert. Das geht natürlich nicht, wenn Du dafür den Primärindex nimmst.
Und außerdem würde ich das in eine Transaktion packen, zur Sicherheit.

[Perlsau]

Zitat von Nersgatt:

Hab mir gerade mal Deinen ersten Post nochmal angeschaut. So bombadierst Du natürlich die Datenbank mit UPDATEs. Je nachdem, wie viele Datensätze Du drin hast.

Vollkommen richtig, bei einer größeren Datensatzmenge dauert das ewig

Die Lösung mit der Zusatzspalte (SeitenNr) ist auf jeden Fall die bessere. Hab vielen Dank für deine Hinweise.