Firebird Datensatz verschieben via PrimaryKey

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

[Perlsau]

Zitat von 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.

Keine Sorge, diesen Fehler mache ich nicht noch einmal
Zumal die Verschiebungen ja mit eingeschaltetem Filter geschehen und deshalb gar nicht alle PrimaryIndexes sichtbar sind:
DatasetBilder.Filter := 'PROJEKTIDX=' + StrToInt(ProjektIndex);

Zitat von mkinzler:

Aber wir sind halt alle Idioten und haben keine Ahnung.

Ganz im Gegenteil, ich profitiere seit Jahren von den Weisheiten der Forenprominenz
(auch wenn sich der finanzielle Profit in Grenzen hält ...)

[Blup]

Zitat von 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.

Bezieht sich das auf meinen Beitrag?
Das man den Primärschlüssel nicht verändert ist ja jetzt hoffentlich allen klar.
Es gibt noch weitere Gründe, die dagegen sprechen und noch nicht genannt wurden (z.B. Lock-Konflikte, OPF, Replication).

Demnach kann das Sortierfeld natürlich nicht der Primärschlüssel sein und ein zusätzlicher Index ist für den schnellen Zugriff auf jeden Fall sinnvoll. Ich schreibe "eindeutiger Index", weil hier sonst leicht Fehler gemacht werden, die den Datenzugriff ausbremsen.
Beispiel, mehrere Touren mit eigenen Anlaufstellen:

Code:

CREATE TABLE T_LIEFERWEG (
/* ... */
    TOUR_ID   INTEGER,
    POS       INTEGER
/* ... */
);

/* die Abfrage */
select * from T_LIEFERWEG where TOUR_ID = :ID order by POS;

/* der für diese Abfrage optimale Index */
CREATE UNIQUE INDEX IDX_LIEFERWEG ON T_LIEFERWEG (TOUR_ID, POS);

[Perlsau]

Meine Sortierungsmethoden sind implementiert und funktionieren mit der zusätzlichen Spalte "SeitenNr" nun genau so, wie sie sollen:

Beim Hoch- und Runterschieben eines Datensatzes werden einfach die Seitennummern zweier untereinanderstehender Datensätze vertauscht. Die restlichen Methoden genauer zu erklären ist mir nun aber doch zu viel, weil es sich um recht viele Sortiermöglichkeiten handelt, wie das Bild im Anhang zeigt ...

Thema kann von mir aus geschlossen werden ...