Reihenfolge von Datensätzen ändern
0 
dedlfix
0 Felix Riesterer
0 0
Reihenfolge von Datensätzen ändern
Hallo,
ich habe folgende db:
+--+----+-------+
|id|name|orderId|
+--+----+-------+
| 1|foo | 2|
| 2|bar | 1|
| 3|fobr| 3|
| 4|brfo| 4|
+--+----+-------+
Die "orderId" dient dazu, eine beliebige Ordnung auf der Menge der Datensätze zu definieren (unabhängig von der "id").
SELECT id, name FROM testTable ORDER BY orderId ergibt dann:
2,bar
1, foo
3, fobr
4, brfo
Soweit, sogut.
Nun sollen von verschiedenen db clients aus Datensätze eingefügt und entfernt werden sowie die Reihenfolge geändert werden können.
U.a. weil ich nicht alle Programme die diese Operationen ausführen selbst schreibe, möchte ich nicht die Hand dafür ins Feuer legen, dass die Folge der "orderId"s immer eine "geschlossene" bleibt.
Also, dass es nach etlichen Einfügen-, Entfernen- und Umsortier-Operationen nicht z.B. die orderId's: "1,2,5,6" vorliegen.
Damit wäre die Sortierte Ausgabe (um die geht es letztlich) immer noch kein Problem, aber das ist doch irgenwie Pfusch!
Hat jemand eine Idee, wie man diese Problem elegant vermeidet / behebt?
Ich könnte eine Prüf-/Reparatur-Routine schreiben, die die Differenz zweier aufeinanderfolgender orderId's berechnet und, falls der nicht eins ist, alle folgenden orderId's entsprechend verringert. Aber das ist mir auch irgendwie ganz schön umständlich...
Gruß
Ralf
-
Tach!
Die "orderId" dient dazu, eine beliebige Ordnung auf der Menge der Datensätze zu definieren (unabhängig von der "id").
Eine ID hat normalerweise sowieso keine andere Funktion als einen Datensatz eindeutig zu identifizieren, also auch keine Sortierfunktion.
Nun sollen von verschiedenen db clients aus Datensätze eingefügt und entfernt werden sowie die Reihenfolge geändert werden können.
U.a. weil ich nicht alle Programme die diese Operationen ausführen selbst schreibe, möchte ich nicht die Hand dafür ins Feuer legen, dass die Folge der "orderId"s immer eine "geschlossene" bleibt.Dann solltest du die Zugriffe nur über Stored Procedures laufen lassen, innerhalb derer du die Konsistenz selbst sicherstellen kannst. Allerdings ist es je nach DBMS auch möglich, direkt INSERT/UPDATE/DELETE aufzurufen und die SP zu umgehen. Hier hilft dann nur Disziplin aller Beteiligten.
dedlfix.
-
Lieber Ralf,
+--+----+-------+
|id|name|orderId|
+--+----+-------+1|foo | 2|
2|bar | 1|
3|fobr| 3|
4|brfo| 4|
+--+----+-------+Also, dass es nach etlichen Einfügen-, Entfernen- und Umsortier-Operationen nicht z.B. die orderId's: "1,2,5,6" vorliegen.
Du willst also keine nicht-vergebenen orderIDs haben, so dass es immer eine orderID gibt, die zwischen 1 und maximalem id-Wert gibt? Warum solltest Du das benötigen?
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:| n4:? de:> ss:| ch:? js:) mo:} zu:) -
Damit wäre die Sortierte Ausgabe (um die geht es letztlich) immer noch kein Problem, aber das ist doch irgenwie Pfusch!
Noch mehr Pfusch ist es, wenn die selbe Ordnungszahl vergeben wird.
Mit Lücken hätte ich kein Problem, aber damit schon eher.Hat jemand eine Idee, wie man diese Problem elegant vermeidet / behebt?
Es muss bei jeder Änderung die Ordnungszahl aller betroffenen Einträge korrigiert werden.
Wenn du einen Eintrag von Position 1 auf Position 100000 schiebst, müssen alle dazwischenliegenden Einträge aktualisiert werden.von verschiedenen db clients
Dann hast du noch ein ganz anderes Problem. Nämlich die Synchronisierung.
Der eine schiebt was nach hinten, der andere nach vorne. Beide speichern ohne von den Änderungen des anderen zu wussen und deine Daten sind dann schnell mal völlig durcheinander. -
Hallo Ralf,
ein ganzzahliger Wert für die Sortierung ist hier vielleicht nicht gerade der ideale Typ. Wenn etwas vor 3 stehen soll, dann könnte das ja auch eine 2.9 sein. Alternativ wäre auch ein zusätzlicher Timestamp eine Überlegung wert.
LG
-
Servus,
ein ganzzahliger Wert für die Sortierung ist hier vielleicht nicht gerade der ideale Typ.
Wieso nicht? 30 ist doch auch n ganzzahliger Wert und der geht wunderbar. Verbraucht auch höchstwahrscheinlich genausoviele Bytes wie eine 3 und dennoch weniger als eine 2.9 :-)
Der grösste Pfusch bleibt allerdings die Idee, diese Serie von Sortierwerten geschlossen zu halten, also ohne Lücken.
Ciao, Frank
-
Der grösste Pfusch bleibt allerdings die Idee, diese Serie von Sortierwerten geschlossen zu halten, also ohne Lücken.
Warum?
Gruß
Ralf-
Tach,
Der grösste Pfusch bleibt allerdings die Idee, diese Serie von Sortierwerten geschlossen zu halten, also ohne Lücken.
Warum?
du siehst ein Problem, wo keines existiert und wirst relativ viel Aufwand haben, das sauber zu lösen.
mfg
Woodfighter
-
-
-