nicht angemeldet
Halihallo Thomas
Millionen von Sätzen werde ich da nicht haben, die das Kriterium erfüllen. Pro Hauptposition wird es vielleicht 20 bis 30 Unterpositionen geben. Man könnte die nun auch nicht geschlossen vorcodieren, also erstmal in 10er-Schritten. Abr irgendwann wird man immer vor dem Problem stehen, dass die Postition schon belegt ist.
Das Problem hast du nur bei Integern. Nimmst du eine Timestamp und sortierst du diese
aufsteigend, hast du die richtige Reihenfolge und kannst die Positions implizit durch
einen Counter in der Programmiersprache setzen; damit umgehst du das Zeitaufwendige
sortieren und neubelegen der Positionen. Eine von einigen Ideen, die ich gestern hatte.
Ziel der ganzen Sache: Du musst erreichen, dass die Unterposition _redundant_ wird.
Du musst versuchen, diese irgendwie implizit "berechnen" zu können; eg. durch Timestamp
Sortierung. Du musst dich von der Unterposition in der Ursprungsform trennen, ansonsten
wirst du immer die gesamte Tabelle überarbeiten müssen (naja, Worst Case).
Ich werde also wohl nicht drum herum kommen, eine Abfrage, ein Update für die Lücke und ein Insert für den neuen Satz zu bauen. Also drei Statements und die müssen ggf. auch noch durch Lock gebunden werden. Allerdings ist es unwahrscheinlich, dass gerade zwei User am selben Nummernkreis fummeln, aber nicht ausgeschlossen.
Nun, wie Michael sagt, ist dieses Vorgehen etwas suboptimal. Es ist kann nicht Zweck der
Sache sein, im Worst-Case alle Records neu zu belegen (POS), nur um einen neuen Record
einzufügen. Die Lösung über einen Baum oder der Timestampmethode von oben wäre vielleicht
etwas besser; hängt jedoch stark von dem ab, was _du_ für eine Aufgabenstellung hast.
Datenbank ist erstmal MySQL, also leider keine Stored Procedures und einfach nen Trigger drauf und gut wärs...
Tja... Warten wir mal die nächsten Versionen ab. VIEW's, Stored Procedures und
Subselects sind ja noch ausstehend...
Viele Grüsse
Philipp