Firebird Datensatz verschieben via PrimaryKey

[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.

[Blup]

Die Bedingungen sollten meiner Meinung nach erfüllt werden:
- der Index auf das Sortierfeld ist eindeutig
- auf die Daten wird auch bei der Änderung über den Index zugegriffen
- die Änderung erfolgt innerhalb einer Transaktion

Ich würde das in einer Stored Procedure kapseln.

Code:

create procedure P_BILDER_VERSCHIEBEN (
    SRCINDEX integer,
    DSTINDEX integer)
AS
begin
  if (srcindex <> dstindex) then
  begin
    if (srcindex < dstindex) then
    begin
      update bilder
      set    idx = -idx
      where  (idx >= :srcindex) and (idx <= :dstindex);
  
      dstindex = -dstindex;
      srcindex = -srcindex;
  
      update bilder
      set    idx = (-idx) - 1
      where  (idx >= :dstindex) and (idx < :srcindex);
    end
    else
    begin
      update bilder
      set    idx = -idx
      where  (idx >= :dstindex) and (idx <= :srcindex);
  
      dstindex = -dstindex;
      srcindex = -srcindex;
  
      update bilder
      set    idx = (-idx) + 1
      where  (idx > :srcindex) and (idx <= :dstindex);
    end
  
    dstindex = -dstindex;
  
    update bilder
    set    idx = :dstindex
    where  (idx = :srcindex);
  end
end

[mkinzler]

Jetzt hatten wir ihn gerade davon überzeugen können, dass man den Primärschlüssel tunlichst nicht anfassen sollte und sich dieser nicht zur Festlegung einer Anzeigereihenfolge eignet. Aber wir sind halt alle Idioten und haben keine Ahnung.