Firebird Datensatz verschieben via PrimaryKey

[Perlsau]

Hallo DelphiPraxler, ich kämpfe mich seit Stunden an einem schier unlösbaren Problem ab:

Gegeben ist eine Tabelle mit JPG-Bildern, die via ProjektIndexspalte verschiedenen Projekten zugeordnet sind. Die Tabelle verfügt über einen Primärschlüssel, dessen Zählung bei 1 beginnt. Die Bilder müssen frei sortiert werden können, denn sie sind dazu bestimmt, in einer vom Anwender gewünschten Reihenfolge ausgedruckt zu werden. Diese Reihenfolge ist nicht zwangsläufig die Reihenfolge, in der sie eingelesen wurden. Natürlich kann man dem Anwender empfehlen, seine Bilddateinamen entsprechend zu wählen und dann einfach die Spalte mit den Dateinamen sortieren. Kurz: Ich habe bereits zwei funktionierende Runter- und Hoch-Prozeduren entwickelt: Man schiebt den ausgewählten Eintrag um eine Position nach oben oder nach unten:

Delphi-Quellcode:

{*********************************************************************************************************************
 *** BILDER SCHIEBEN                                                                                               ***
 *********************************************************************************************************************}
PROCEDURE TDatMod.BilderTausch(Bild1,Bild2 : LongInt);
BEGIN
     Dset_Bilder.Filtered := FALSE;
     DatesetsTrennen;

     Query_Main.Close;
     Query_Main.SQL.Clear;
     Query_Main.SQL.Append('update BILDER set IDX_BILDER = 0');
     Query_Main.SQL.Append('where IDX_BILDER = ' + IntToStr(Bild1));
     Query_Main.ExecQuery;

     Query_Main.SQL.Clear;
     Query_Main.SQL.Append('update BILDER set IDX_BILDER = ' + IntToStr(Bild1));
     Query_Main.SQL.Append('where IDX_BILDER = ' + IntToStr(Bild2));
     Query_Main.ExecQuery;

     Query_Main.SQL.Clear;
     Query_Main.SQL.Append('update BILDER set IDX_BILDER = ' + IntToStr(Bild2));
     Query_Main.SQL.Append('where IDX_BILDER = 0');
     Query_Main.ExecQuery;

     DatesetsVerbinden;
     Dset_Bilder.Filtered := TRUE;
END;

{*********************************************************************************************************************
 *** AKTUELLES PROJEKTBILD EINE POSITION NACH OBEN                                                                 ***
 *********************************************************************************************************************}
PROCEDURE TDatMod.BildHoch;
VAR
   Bild1, Bild2 : LongInt;

BEGIN
     IF Dset_Bilder.RecNo = 1 THEN EXIT;

     Dsrc_Bilder.Enabled  := FALSE;

     Bild1 := Dset_Bilder.FieldByName('IDX_BILDER').AsVariant;
     Dset_Bilder.Prior;
     Bild2 := Dset_Bilder.FieldByName('IDX_BILDER').AsVariant;

     BilderTausch(Bild1,Bild2);

     Dset_Bilder.Locate('IDX_BILDER',Bild2,[]);
     Dsrc_Bilder.Enabled  := TRUE;
END;

{*********************************************************************************************************************
 *** AKTUELLES PROJEKTBILD EINE POSITION NACH UNTEN                                                                ***
 *********************************************************************************************************************}
PROCEDURE TDatMod.BildRunter;
VAR
   Bild1, Bild2 : LongInt;

BEGIN
     IF Dset_Bilder.RecNo = Dset_Bilder.RecordCount THEN EXIT;

     Dsrc_Bilder.Enabled  := FALSE;

     Bild1 := Dset_Bilder.FieldByName('IDX_BILDER').AsVariant;
     Dset_Bilder.Next;
     Bild2 := Dset_Bilder.FieldByName('IDX_BILDER').AsVariant;

     BilderTausch(Bild1,Bild2);

     Dset_Bilder.Locate('IDX_BILDER',Bild2,[]);
     Dsrc_Bilder.Enabled  := TRUE;
END;

Der ausgewählte Eintrag wandert um eine Position nach oben bzw. nach unten. (Bild 1).

Nun möchte ich aber gerne einen Eintrag ganz nach oben bzw. ganz nach unten verschieben können. Dazu hab ich mir gedacht, führst du die Nach-Oben- bzw. Nach-Unten-Prozedur so oft aus, bis der Eintrag dort steht, wo er stehen soll: Ich hole mir erstmal den Index für den aktuellen Eintrag (BildAktuell), danach den für den ersten Eintrag (BildFirst), wechsle mit Locate wieder zu BildAktuell und schiebe diesen um eins nach oben. Da ja beim Verschieben um eine Position die Markierung weiterhin auf dem gewählten Eintrag sitzten sollte (Bild 1), wovon ich erstmal ausging, rufe ich einfach BildHoch auf und setze danach BildAktuell auf den neuen Wert. Auch das funktioniert beim ersten Durchlauf der Repeat-Schleife noch einwandfrei: BildAktuell enthält nun den Wert des Primary-Index der vorher davorstehenden Eintrags. Mit anderen Worten: BildAktuell enthielt zuvor den Wert 8, nun den Wert 7. Da ich 8 Einträge für dieses Projekt habe, sollte nun die RecordNo ebenfalls auf 7 stehen. Doch seltsamerweise steht sie weiterhin auf 8. Das führt dazu, daß beim nächsten Durchlauf der untenstehenden Repeat-Schleife die beiden Einträge mit den P-Keys 7 und 8 wiederum vertauscht werden, also eine Endlosschleife entsteht.

Delphi-Quellcode:

{*********************************************************************************************************************
 *** AKTUELLES PROJEKTBILD AN DEN ANFANG DER LISTE SETZEN                                                          ***
 *********************************************************************************************************************}
PROCEDURE TDatMod.BildAnfang;
VAR
   BildFirst,
   BildAktuell : LongInt;

// GetBildIndex
FUNCTION GetIdx : LongInt;
BEGIN
     Result := Dset_Bilder.FieldByName('IDX_BILDER').AsVariant;
END;

// Hauptprocedure
BEGIN
     IF Dset_Bilder.RecNo = 1 THEN EXIT;

     Dsrc_Bilder.Enabled  := FALSE;

     BildAktuell := GetIdx;
     Dset_Bilder.First;
     BildFirst   := GetIdx;
     Dset_Bilder.Locate('IDX_BILDER',BildAktuell,[]);

     REPEAT
           BildHoch;
           BildAktuell := GetIdx;

     UNTIL BildAktuell = BildFirst;


     Dsrc_Bilder.Enabled  := TRUE;
END;

[mkinzler]

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

[Perlsau]

Zitat:

Zitat von mkinzler (Beitrag 1157649)

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 :-D

[Perlsau]

Zitat:

Zitat von Nersgatt (Beitrag 1157654)

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.

[Perlsau]

Zitat:

Zitat von mquadrat (Beitrag 1157658)

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

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

[Nersgatt]

Zitat:

Zitat von Perlsau (Beitrag 1157660)

Zitat:

Zitat von Nersgatt (Beitrag 1157654)

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... :stupid:

[Perlsau]

Zitat:

Zitat von Nersgatt (Beitrag 1157662)

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... :stupid:

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.:-D

Was ist eigentlich mit deiner I-Taste los?:stupid:

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

Zitat von Nersgatt (Beitrag 1157671)

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 :lol:

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

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

Zitat von mkinzler (Beitrag 1157927)

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 :idea:
Zumal die Verschiebungen ja mit eingeschaltetem Filter geschehen und deshalb gar nicht alle PrimaryIndexes sichtbar sind:

Delphi-Quellcode:

DatasetBilder.Filter := 'PROJEKTIDX=' + StrToInt(ProjektIndex);

Zitat:

Zitat von mkinzler (Beitrag 1157927)

Aber wir sind halt alle Idioten und haben keine Ahnung.

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

[Blup]

Zitat:

Zitat von mkinzler (Beitrag 1157927)

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