[MySQL] Extra Integer anlegen für Relationen?

Tommy57

Erfahrenes Mitglied
Hallo,

ich brauche mal eure Meinung.

Ich habe die zwei Datenbanktabellen User und Video, mit denen ich sehr viele Verknüpfungen aufbauen muss. Beide Tabellen haben aktuell einen Primary als CHAR(32) und CHAR(11).

Meine Frage:

Soll ich bei beiden Tabellen extra eine Spalte id (autoincrement INT) ergänzen, damit ich dann die Tabellen über ein Integer verknüpfe oder kann ich ohne Probleme auch die aktuellen Primaries (CHARs) verwenden? Die extra ID Spalte wäre dann nur für Relationen, sonst brauch ich die gar nicht.

Es könnte möglich sein, dass einige der Tabellen in den nächsten Jahren die Millionen Zeilen erreichen werden und ich möchte jetzt schon vorbeugen, dass die Tabellen dann nicht zu langsam werden, weil ich Zählungen und Vergleiche auf CHARs mache?

Weiß jemand, ob CHAR(32) bzw CHAR(11) bedeutend langsamer ist als Integer. Vom Speicherverbrauch her würde ja glaub ich ein CHAR(4) einem Integer entsprechen.

Gruß, Tommy
 
Hallo Tommy,

wie bei vielem gibts keine klare Ja/Nein Antwort.

Es kommt darauf an, WAS du mit dem Primary Key vor hast. Grundsätzlich sind Integer-based Key´s (mit Index) am schnellsten vom System zu selektieren. Allerdings je nach verwendetem Integer Typ ist da auch mal schnell Ende, gerade im Big Data Segment.

Ich würde grundsätzlich auf der Database-Ebene nur Integer-Based Key´s verwenden. Solltest du für bestimmte Elemente Char-based Key´s brauchen, würde ich die als zweite UNIQUE INDEX Spalte mitführen. Aber die eigentlichen Constraints auf basis der Integer Werte aufbauen.

Außnahme die Char-based Key´s definieren mir mehr wie ein Datenbankobjekt.

Allerdings in deinem Fall ist das jetzt leichter Overkill. Du kannst auch auf dem Char Feld die Constraints aufbauen, du musst nur beachten, dass die Char Felder in der referenzierten Tabelle als UNIQUE oder PRIMARY definiert ist. Sonst wirft dir MySQL einen Fehler.

Was die Selektionsgeschwindigkeit betrifft, kann ich jetzt wenig sagen. Ich verwende wie gesagt fast ausschließlich Integerbases Key´s.

Probiers einfach aus. Aber ich bezweifel, dass du hier größere Probleme bekommst. Das System wird etwas mehr CPU Leistung + RAM für die Abfragen brauchen, auf Grund der größeren Felder, aber ansonsten

Gruss
SK
 
Du könntest ja einmal 2 Tests erstellen. Z.B. erstelle zwei Kopien deiner Tabellen mit einer zusätzlichen ID INT Spalte und füll die mal mit 1 Million Testdaten.
Du kannst z.B. das hier verwenden als Rowgenerator:
http://use-the-index-luke.com/blog/2011-07-30/mysql-row-generator#mysql_generator_code

Und dann mach nochmals das gleiche nur diesmal schreib 1 Million Testdaten wo der PK CHAR ist. Du könntest ja evtl. die INT ID aus dem Generator als HEX abspeichern.

Und anschliessend mach mal deine Joins und schaue wie sich das verhält bei dir.
 
Hi,

danke für euren schnellen Antworten. Hatte vorhin schon einen Benchmark gefunden. Es ist so wie zu erwarten, dass je länger der CHAR ist, umso langsamer werden die Operationen darauf. Nebenbei hat der Primary Int noch den Vorteil, dass er sich schnell sortieren (nach Erstellungsdatum) lässt.

Ich habe mich jetzt für den Primary Int entschieden. Neben der Performance ist es auch besser, einen zuverlässigen eindeutigen unabhägigen Schlüssel zu haben. Dieser CHAR(11) zB ist ja von YouTube und es liegt somit nicht in meiner Macht, wenn sich da mal was ändert.

Gruß, Tommy
 
Zurück