Große Lücken in der Identitätsspalte

[zachy]

Hallo Forum,

ich habe folgendes Problem: ich habe in meinem SQL-Server 2014 eine Tabelle mit einer Identitätsspalte (Datentyp Integer) als Primärschlüssel. Beim Einfügen von Datensätzen in diese Tabelle stelle ich fest, dass in der Identitätsspalte die Nummern nicht fortlaufend sind, sondern große Lücken existieren.

Beispiel: Sagen wir mal, dass der letzte Eintrag in der Identitätsspalte den Wert 30 hat. Der nächste Datensatz, den ich in die Tabelle einfüge, erhält in der Identitätsspalte den Wert 1007. Dann geht es weiter mit 1008, 1009, 1010 etc. und auf einmal geht es weiter mit 2030.

Wie kann es sein, dass hier so große Lücken auftreten? In den Eigenschaften der Identitätsspalte ist festgelegt:

Id-Ausgangswert: 1

ID-Inkrement: 1

Eigentlich müsste doch die Nummerierung fortlaufend sein, oder?

Kann mir jemand helfen?

Viele Grüße

zachy

 

[Dukel]

Wurden Daten daraus gelöscht?

 

[zachy]

Nein, es werden keine Daten gelöscht. Ich bin auch der einzige, der die Datenbank benutzt, sodass ich ausschließen kann, dass Daten gelöscht werden.

 

[akretschmer]

Eigentlich müsste doch die Nummerierung fortlaufend sein, oder?

Ja. Exakt das ist sie. Verwechsle "fortlaufend" bitte nicht mit "lückenlos". Ich kenne M$SQL nicht, hier aber einige Gründe in PostgreSQL, wie solche Lücken entstehen können:

• Transaktionen wurden zwischendrin zurückgerollt. Der Klassiker.
• Sequence wurde mit einem Cache-Wert erstellt. Daß führt dazu, daß sich eine Session schon mal so wie Werte sichert, wie der Cache-Wert es definiert
• in einer Multi-Master-Umgebung (BDR) kann man unterschiedliche Strategien verwenden, um Konflikte mit automatisch generierten ID's zu vermeiden. Eine ist, daß jeder Master sich aus einem Pool einen Block von IDs holen kann. Also ein Master fordert einen Block von 100 IDs an, bekommt 100-199, ein anderer Master bekommt 200-299.
• wieder Multi-Master: bei N möglichen Mastern werden am Master 1 die Sequence mit 1 beginnend und Offset N definiert, Master3 mit 3 beginnend und Offset N. Sei N gleich 10, so bekommt Master 5 z.B. 5, 15, 25, 35 ...
• wieder Multi-Master: BDR2 hat einen mathematischen Algorithmus eingebaut, der für bis zu 1000 Nodes und bis zum Jahre 2042 je Node 8 Millionen ID's je Sekunde generiert - konfliktfrei. Die IDs sind aufsteigend, aber nicht lückenlos.

Im übrigens kann man ID-Spalten auch als UUID definieren. Das ist dann nicht aufsteigend und auch nicht lückenfrei, aber immer noch konfliktfrei (so hofft man ...)

 

[ukulele]

Lücken sind technisch gesehen auch erstmal kein Problem und sollten auch für deine Abfragen kein Problem darstellen, sonst wäre das eher ein Mangel. Das die Lücken bei einer so "simplen" Datenbank entstehen sollen finde ich allerdings auch merkwürdig, aber erlich gesagt habe ich die Funktion nie genutzt sondern immer GUIDs verwendet.

 

[zachy]

Hallo Leute, danke für eure Antworten. Vielleicht steige ich wirklich auf die GUID's um...

Meine Sorge ist halt, dass man durch diese große Sprünge in den ID-Werten schnell den maximalen ID-Wert erreicht und dann einfach keine neuen Datensätze mehr in die Tabelle einfügen kann... Ich meine, bei einem Wertebereich bis ca. 2 Mrd. ist das natürlich ne Weile hin, aber es sollen ja automatisiert täglich mehrere Einträge gemacht werden.

Auch das mit den Sequences werde ich mir mal anschauen.

Viele Grüße

zachy

 

[akretschmer]

Bigint-Sequencen gehen bis 9223372036854775807. Wenn Du pro Sekunde 1000 ID's verbrätst, reicht das noch immer für 292471208 Jahre.