Hello,
das bribgt mich noch eine andedre Frage:
Wenn man eine "Sortierrang-Spalte" hat, und will Beiträge umsorieren, dann kommt es ja vor, dass der Zielrang bereits belegt ist, also keine Lücke im Nummernkreis vorhanden ist.
12 36789ACF K
^ |
+---------+
Also der Satz K soll nun beispielsweise VOR dem Rang 3 einsortiert werden.
(Die Buchstaben habe ich hier nur wegen der besseren Lesbarkeit, der Rang ist in der Tabelle eine rein numerische Größe!)
Nun müsste ich zuvor ja ein Update-Query durchführen:
Update $table set rang = rang +1 where rang <= 3 and $sonstigeFilter;
Ist das mit allen gängigen SQL-DBMS so zulässig? Schließlich wird die Indizierte Spalte selber geändert. Bei Desktopdatenbanken konnten solche "Selbstbezugabfragen" zu verheerenden Folgen führen.
12 4789ABDG L
^ |
+---------+
Dann müsste die Tabelle hinterher so aussehen.
Wahrscheinlich müsste man auch bei SQL die Tabelle für eine Vertikalmanipulation sperren, oder werden die Queries ausreichend serialisiert? Der ganze Vorgang besteht ja aus drei Teilen:
- Stelle suchen und merken
- Lücke schaffen
- Datensatz einfügen
Erst danach dürften andere Queries wieder in der Tabelle rumfummeln.
Die obige Betrachtung ist mir noch einigemaßen flüssig aus der Tastatur gequollen, aber wie sieht es nun aus, wenn man aus der rangfolge einen Satz löscht:
1236789ACF K
|
v
danach sieht die Rangfolgespalte dann so aus:
12 6789ACF K
Im Prinzip wäre sie für die rechnerische Bearbeitung vielleicht schon kaputt so. Vielleicht dürfte man gar keine Lücken entstehen lassen. Wie könnte man aber diese Lücken nun wieder schließen, also die Datensätze aus dem Filterbereich wieder Lückenlos von 1 bis n durchnumerieren, ohne ihre aktuelle Rangfolge zu zerstören. Das ganze natürlich mit minimaler Anzahl von Queries. Es könnten in der Praxis schon mal 250 Datensätze in einem Filterbreich werden.
Um es praktich zu hinterlegen:
Ich habe Angebote zu verschiedenen Kategorien. Die werden innerhalb ihrer Kategorie immer nach einer subjektiven Rangfolge sortiert. Es kpmmt häfiger vor, dass ein Angebot aus einer Kategorie in eine andere verschoben wird.
( Das ganze Spielchen war bei bTrieve kein Problem, da die Datenhaltung dort tabellenintern mit einer verketten Liste stattfindet und man nur Vorgänger und Nachfolger miteinander verknüpfen musste. Problem ist da dann das Duplicatemanagement. )
Also nochmal die Frage:
Wie würdet Ihr eine SQL-Statementgruppe aufbauen, um eine Datensatzgruppe durchzunumerieren? Funktionieren die SQL-User-Variablen in der 4er Version von MySQL?
Liebe Grüße aus http://www.braunschweig.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen