• Jetzt anmelden. Es dauert nur 2 Minuten und ist kostenlos!

Performancefrage: „Lückenhafter“ Primärschlüssel

vitus37

Senior HTML'ler
Guten Abend,

ich arbeite derzeit an einer Facebook-Anwendung und muss die übergebenen Benutzer-IDs in einer MySQL-Datenbank abspeichern.

Da jede ID nur ein Mal vorkommt, kann ich sie prinzipiell als Primärschlüssel speichern. Meine Befürchtung ist jedoch, dass die MySQL-Engine zum durchsuchen der DB dann länger braucht, da die IDs weder in chronologischer Reihenfolge, noch vollständig sind (zwischen zwei Nummern kann eine Differenz von mehreren Tausenden bestehen, schließlich habe ich nicht alle Facebook-IDs).

Vor allem diese großen Lücken zwischen den IDs lassen mich zweifeln. Die Position eines DB-Eintrags in einer MySQL-Datei wird ja - soweit ich weiß - aus der Größe eines Eintrags und der ID errechnet. Das ist nicht möglich, wenn tausende Einträge fehlen.

Jetzt könnte ich auch eine weitere Spalte anlegen, in welcher ich eine eigene ID-Liste anlege und als Primärschlüssel setze.
Code:
Facebook-ID    |    Eigene-ID
------------------------------
123456789123   |    1
892545986921   |    2
345892046512   |    3
Doch bin der Meinung, dass das eine Form von Redundanz ist. Beide Spalten haben eigentlich den selben Zweck.

Hat jemand eine bessere Idee oder kann mich über die Performance der ersteren Methode aufklären?

MfG
Vitus
 
Zuletzt bearbeitet:
Werbung:
Ein Schlüssel kann auch über mehrere Felder gehen. Ob das sinnvoll ist entscheidet sich am konkreten Anwendungsfall. Ansonsten kann die Facebook-ID (erscheint mir sinnvoller) auch ein Unique und ggf. mit einem Index sein.
 
Mir erscheint's spontan auch schöner, die Facebook-ID gewissermaßen als „Fremdschlüssel“ zu verwalten. Ich kann allerdings nicht begründen, wieso.

Vor allem diese großen Lücken zwischen den IDs lassen mich zweifeln. Die Position eines DB-Eintrags in einer MySQL-Datei wird ja - soweit ich weiß - aus der Größe eines Eintrags und der ID errechnet. Das ist nicht möglich, wenn tausende Einträge fehlen.

Das Gedankenbeispiel war zwar nicht falsch, aber eben stark vereinfacht. Es sollte zeigen, was eine Datenbank grundsätzlich an Optimierungsstrategien anwendet, um effizient einen bestimmten Datensatz zu ermitteln, ohne alle Datensätze „davor“ durchgehen zu müssen, nur um die passende Position zu bestimmen.

Ein DB-Index wird „in Wahrheit“ zumeist in einer Baumstruktur organisiert.

- B+-Baum

Dabei zählen primär „größer/kleiner“-Beziehungen, für die Lücken relativ gleichgültig sind.
 
Werbung:
Danke euch beiden.

Setze die Facebook-ID jetzt als UNIQUE-Fremdschlüssel und erzeuge ein weiteres Feld mit Primärschlüssel.

Gruß
 
Zuletzt bearbeitet:
Zurück
Oben