Primärschlüssel mit uniqid()

[Mik3e]

Mahlzeit!

Hat vielleicht schon jemand von Euch Erfahrung mit dem Erzeugen eines künstlichen Primärschlüssels mittels uniqid() für einen MySQL Table?

Sollte nach möglichkeit eine 10-Stellige Bigint Zahl sein, die wirklich eindeutig ist. Ich kann leider keinen autoincrement oder einen Natürlichen Schlüssel verwenden, da hier über geraume Zeit mehrere Millionen Datensätze gespeichert werden. Daher stößt ein künstlicher Schlüssel mit auto increment über kurz oder lang an seinen "Typen"-Grenzen.

Eignet sich uniqid() zum Erzeugen eines eindeutigen Schlüssels Oder ist davon eher abzuraten?

Danke & LG
Mike

 

[hpvw]

Zu [phpf]uniqueid[/phpf] kann ich Dir leider nichts konkretes sagen. Ich würde jedenfalls nicht auf die Eindeutigkeit vertrauen.
Ein UNSIGNED INT hat jedoch bereits einen Wertebereich, der über 4 Milliarden hinausgeht. Der Wertebereich eines UNSIGNED BIGINT geht bis
achzehn Trillionen
vierhundertsechsundvierzig Billiarden
siebenhundertvierundvierzig Billionen
dreiundsiebzig Milliarden
siebenhundertneun Millionen
und fünfhunderteinundfünfzigtausendsechshundertsechzehn
(18.446.744.073.709.551.616 = 2 hoch 64).
Und das soll bei mehreren Millionen Datensätzen nicht ausreichen?

Gruß hpvw

 

[Mik3e]

Das Problem ist, dass in dieser Tabelle riesige Arrays gespeichert werden (jedes Element eines Array = 1 Datensatz).

Es geht genaugenommen um eine Platzverwaltung. Dort hat ein Sektor schnell 500x500 Elemente = 250.000 Datensätze.

Und natürlich kann es jede Menge Sektoren geben. Und diese Sektoren sind wieder definierten Orten zugewiesen (von denen es auch mehrer tausend geben kann).

Wahrscheinlich reicht ein BIGINT(20) für die ersten paar Monate aus, ich hab aber nicht wirklich Lust, nach z.B. einem Jahr das ganze ERD neu zu designen, nur weil ich am Ende des Wertebereichs angelangt bin...

Alle anderen Primärschlüssel sind sowieso mit BIGINT abgebildet. Zumindest jene Tabellen, bei denen ich mit weniger Datensätzen rechne...

Hast Du zufällig die URL zur Typendeklaration (Wertbereiche) in MySQL

Danke & LG
Mike

 

[Mik3e]

Ach ja, nochwas:
Gibt es noch einen größeren Typ als BIGINT? (höherer Wertebereich)?

 

[hpvw]

http://dev.mysql.com/doc/mysql/en/numeric-types.html
Ich habe mich übrigends vertan:
Es gibt die oben genannte Anzahl unterschiedlicher Werte, aber da die 0 ja auch eine Zahl im Wertebereich ist, musst Du für die größtmögliche Zahl eines UNSIGNED BIGINT eins abziehen.
Größer als UNSIGNED BIGINT ist mir nicht bekannt.
Gerade bei einem so großen Datenbestand solltest Du Dir über die Performanceverluste im Klaren sein, wenn Dein Primärschlüssel kein ganzzahliger Typ ist.
Dir ist klar, dass Du mit einem UNSIGNED BIGINT rund 73 Billionen Deiner Sektoren in der Tabelle ablegen kannst?
Wenn Du eine Beziehung zu Orten herstellst, spielt das Produkt aus Orten und Sektor-Elementen keine Rolle. Du wirst hoffentlich eine Verknüpfungstabelle für die beiden Typen haben, in dieser muss dann nur ein zusammengesetzter Primärschlüssel aus der Orte-ID und der Sektor-Element-ID angelegt werden.

Gruß hpvw

 

[Mik3e]

Ich glaube, wir haben aneinander vorbeigeredet..
Das ERD besteht aus 3 Ebenen (siehe abbildung)... Eine simple, doppelte 1:n beziehung...

Ich verwende immer UNSIGNED ZEROFILL.. Ich nehme an der Wertebereich ändert sich dann nicht, oder? (einzig die leeren Stellen werden mit 0 aufgefüllt).

LG
Mike

 

[Gumbo]

Um mal den Wertebereich von der PHP-Funktion uniqid() und dem MySQL-Spaltentyp BIGINT mit der Eigenschaft UNSIGNED zu vergleichen: uniqid() liefert einen nur 13-stelligen Hexadezimalwert mit 16¹³ möglichen Kombinationen. Die BIGINT mit UNSIGNED-Eigenschaft besitzt jedoch einen Wertebereich von 2?? entspricht. Du könntest jedoch auch die MD5-Prüfsumme des uniqid()-Werts errechnen, damit kämst du nur auf 16³² Möglichkeiten.

 

[hpvw]

In der Saalplansektor-Tabelle kannst Du über 73 Billionen Datensätze haben, wenn jeder dieser Datensätze 250.000 assozierte Datensätze in der Saalplanplatz-Tabelle hat.
Ich denke von der Aussage her hat sich nichts geändert, auch wenn wir geringfügig aneinander vorbei geredet haben.

Gruß hpvw

 

[Mik3e]

Moment:
Ich dachte uniqueid() errechnet seinen Wert anhand des Unix Timestamps sowie zusätzlicher komponenten?

Im Prinzip bräuchte ich nur eine Lösung, wie Sie bei Rechnungsnummer häufig der Fall ist:
<DATUM><Laufende Rechnungsnummer an diesem Tag>

Damit hat man eine sehr eingeschränkte breite und eine 100% eindeutigkeit gegeben. Natürlich sind auch hier durch die Typendeklaration Grenzen gesetzt (z.B. 10.000 Rechnung / Tag), was aber durchaus gesteuert werden kann.

Ich war der Meinung, uniqueid() arbeitet nach einem ähnlichen Model!?

 

[hpvw]

Um mal den Wertebereich von der PHP-Funktion uniqid() und dem MySQL-Spaltentyp BIGINT mit der Eigenschaft UNSIGNED zu vergleichen: uniqid() liefert einen nur 13-stelligen Hexadezimalwert mit 16¹³ möglichen Kombinationen. Die BIGINT mit UNSIGNED-Eigenschaft besitzt jedoch einen Wertebereich von 2?? entspricht. Du könntest jedoch auch die MD5-Prüfsumme des uniqid()-Werts errechnen, damit kämst du nur auf 16³² Möglichkeiten.

Wie willst Du denn aus 16 hoch 13 verschiedenen Werten 16 hoch 32 verschiedene Werte machen?
16 hoch 13 ist übrigends weniger als 2 hoch 64, um das Ergebnis des Vergleichs auch noch zu nennen.

Gruß hpvw