Records mit einem Unique Key in Lücke aufrücken lassen

[QuickAndDirty]

Es wird benutzt um Positions-Dubletten innehalb einer Gruppe zu verhindern. Jeder Datensatz hat eine eindeutige ID.....der Primärschlüssel halt .
Ich wusste nicht das diese Funktionalität von Schlüsseln ein Missbrauch ist. Dachte an sich immer, dass es weitverbreitete Praxis ist.

[Redeemer]

Wie können beim Löschen Dubletten auftreten?

[Jasocul]

Ich glaube fast, dass es hier ein generelles Missverständnis gibt.
Der PK ist das Feld "ID".
Dann gibt es zusätzlich eine GruppenID und eine Position, die in Kombination ein UK sind.
Wenn ich dabei an eine WaWi denke, könnte GruppenID eine Auftragsnummer sein und Position die laufende Positionsnummer.
Löscht man eine der Position (z.B. Nr 3 von 500), möchte man die Positionsnummern neu vergeben, damit keine Lücken entstehen.
Die Aussage, dass das eine Prüfung der Dubletten sein soll, ist vermutlich unglücklich formuliert. Ich gehe davon aus, dass durch den kombinierten UK doppelte Positionsnummern in einem "Auftrag" bei der Erfassung verhindert werden sollen. Es stellt sich dabei natürlichdie Frage, wie das passieren sollte, da man üblicherweise Positionsnummern nicht manuell vergibt, aber das ist ein anderes Thema.

Firebird kennt "with" und das gilt inzwischen eigentlich für alle aktuellen Datenbanken.
Nimmt man in das With eine sortierte SQL-Abfrage und joined das im Update-Statement, kann man vermutlich die Positionen neu durchnummerieren.
Bitte selbst testen, da es nicht schwierig ist und ich auch kein Firebird zur Verfügung habe, um das zu prüfen.

[QuickAndDirty]

Zitat von Jasocul:

Ich glaube fast, dass es hier ein generelles Missverständnis gibt.
Der PK ist das Feld "ID".
Dann gibt es zusätzlich eine GruppenID und eine Position, die in Kombination ein UK sind.
Wenn ich dabei an eine WaWi denke, könnte GruppenID eine Auftragsnummer sein und Position die laufende Positionsnummer.
Löscht man eine der Position (z.B. Nr 3 von 500), möchte man die Positionsnummern neu vergeben, damit keine Lücken entstehen.
Die Aussage, dass das eine Prüfung der Dubletten sein soll, ist vermutlich unglücklich formuliert. Ich gehe davon aus, dass durch den kombinierten UK doppelte Positionsnummern in einem "Auftrag" bei der Erfassung verhindert werden sollen. Es stellt sich dabei natürlichdie Frage, wie das passieren sollte, da man üblicherweise Positionsnummern nicht manuell vergibt, aber das ist ein anderes Thema.

Firebird kennt "with" und das gilt inzwischen eigentlich für alle aktuellen Datenbanken.
Nimmt man in das With eine sortierte SQL-Abfrage und joined das im Update-Statement, kann man vermutlich die Positionen neu durchnummerieren.
Bitte selbst testen, da es nicht schwierig ist und ich auch kein Firebird zur Verfügung habe, um das zu prüfen.

Ich lese mir mal "With" durch!

[QuickAndDirty]

Zitat von Redeemer:

Wie können beim Löschen Dubletten auftreten?

Beim Löschen keine!
Beim Aufrücken in die freie Position kann das passieren je nach dem in welcher reihenfolge der SQLServer die Datensätze bearbeitet.

Code:

UPDATE "TABELLE" SET "ZEILENPOSITION" = "ZEILENPOSITION" -1

Wenn UPDATE zuerst Datensätze mit der kleinsten "ZEILENPOSITION" bearbeitet dann haben wir keine Doubletten
Wenn UPDATE aber mit einer Anderen "ZEILENPOSITION" beginnt als mit der Kleinsten, dann havben wir temporär Doubletten und die UNIQUE KEY CONSTRAINT schlägt zu.

[Delphi.Narium]

Hier gibt es mehrere Vorschläge, die eventuell hilfreich sein könnten: How to update and order by using ms sql

[Blup]

So ein Sortierfeld ist in den meisten Fällen vom Typ Integer, aber enthält nur positive Werte.
Damit während des Sortiervorgangs ein eindeutiger Index auf diesem Feld nicht verletzt wird, kann man den Vorgang innerhalb einer Transaktion in zwei Schritte aufteilen:
- für allen zu veränderden Datensätzen den vorhandenen Wert negierten
- die negierten Werte durch die neuen positiven Werte ersetzen

[Frickler]

Zitat von Blup:

So ein Sortierfeld ist in den meisten Fällen vom Typ Integer, aber enthält nur positive Werte.
Damit während des Sortiervorgangs ein eindeutiger Index auf diesem Feld nicht verletzt wird, kann man den Vorgang innerhalb einer Transaktion in zwei Schritte aufteilen:
- für allen zu veränderden Datensätzen den vorhandenen Wert negierten
- die negierten Werte durch die neuen positiven Werte ersetzen

Oder im ersten Schritt eine große Konstante (z.B. 1.000.000) auf alle Nummern aufaddieren.

[himitsu]

Oder die ID eine ID sein lassen und ein anderes Feld zum Sortieren benutzen.

[QuickAndDirty]

Zitat von Blup:

So ein Sortierfeld ist in den meisten Fällen vom Typ Integer, aber enthält nur positive Werte.
Damit während des Sortiervorgangs ein eindeutiger Index auf diesem Feld nicht verletzt wird, kann man den Vorgang innerhalb einer Transaktion in zwei Schritte aufteilen:
- für allen zu veränderden Datensätzen den vorhandenen Wert negierten
- die negierten Werte durch die neuen positiven Werte ersetzen

Ja, das war ja auch mein erster weg dieses Problem zu lösen. Siehe beispiel im Eröffnungspost.
Ich wollte nur wissen ob es bessere Wege gibt.