Zeichen vs Integer-Primärschlüssel

Ich entwerfe eine Datenbank mit mehreren Nachschlagetabellen, die mögliche Attribute der Hauptentitäten enthalten. Ich denke an die Verwendung eines Schlüssels mit 4 oder 5 Zeichen, um diese Nachschlagewerte zu identifizieren, anstatt eine automatisch inkrementierende Ganzzahl. Wenn ich diese Attribut-IDs in den Haupttabellen speichere, werden aussagekräftige Werte und nicht nur Zufallszahlen angezeigt.

Welche Auswirkungen hat die Verwendung eines Zeichenfelds als Primärschlüssel und nicht als Ganzzahl auf die Leistung?

Ich benutze MySQL, wenn das wichtig ist.

[Bearbeiten] In
diesen Nachschlagetabellen werden nur selten neue Datensätze hinzugefügt. Sie werden manuell gepflegt und die zeichenbasierten Schlüssel werden ebenfalls manuell erstellt. Hier ist ein Beispiel:

      CUISINES
 ID      Description
-----  --------------
CHNSE  Chinese
ITALN  Italian
MXICN  Mexican

Es hängt von Ihrem Motor ab. Es ist allgemein bekannt, dass Lesevorgänge billig sind, ein paar Bytes hier und da haben keinen signifikanten Einfluss auf die Leistung einer kleinen bis mittelgroßen Datenbank.

Noch wichtiger ist, dass dies von den Verwendungszwecken abhängt, für die Sie den Primärschlüssel verwenden. Integer-Serien haben den Vorteil, dass sie einfach zu verwenden und zu implementieren sind. Abhängig von der spezifischen Implementierung der Serialisierungsmethode haben sie auch den Vorteil, dass sie schnell abgeleitet werden können , da die meisten Datenbanken die Seriennummer nur an einem festen Ort speichern, anstatt sie sofort abzuleiten Select max(ID)+1 from foo.

Es stellt sich die Frage, wie ein 5-stelliger Schlüssel für Sie und die Anwendung einen "sinnvollen Wert" darstellt. Wie wird dieser Wert erstellt, und dauert es mehr oder weniger als eine inkrementelle Seriennummer zu finden. Während in einigen ganzen Zahlen nur eine geringe Menge an Speicherplatz eingespart wird, ignoriert die überwiegende Mehrheit der Systeme diese Platzersparnis.

Es gibt keine Auswirkungen auf die Leistung, außer dass das Zeichenschema erfordert, dass es niemals eine automatische Engine gibt, da Ihre "Schlüssel" nicht möglich sind. Machen Sie sich für Ihre Domain keine Gedanken über künstliche Schlüssel und verwenden Sie einfach Chinesisch, Japanisch und Thailändisch als Schlüsselnamen. Obwohl Sie keine Garantie für die Eindeutigkeit einer möglichen Anwendung geben können, ist es in Ihrem Anwendungsbereich viel sinnvoller, sie anstelle von schrecklichen und erzwungenen 5-Zeichen-Abkürzungen zu verwenden. Es gibt keine signifikanten Leistungseinbußen, bis Sie die Millionen von Tupeln erreichen.

Wenn Sie nur nach Herkunftsland und nicht nach bestimmten regionalen Küchen suchen (Kantonesisch, Sichuan, Sizilianisch, Umbrisch, Kalabrisch, Yucatecan, Oaxacan usw.), können Sie immer nur ISO 3166-Codes verwenden .

Wenn ich 10.000 Rezepte habe, summiert sich dann nicht der Unterschied zwischen einem 5-stelligen und einem 20-stelligen Schlüssel?

Platz ist billig . Wenn Sie über 10.000.000 Rezepte sprechen, mit denen Sie OLAP-Vorgänge ausführen, dann vielleicht. Bei 10.000 Rezepten stehen 150.000 Speicherplätze zur Verfügung.

Aber es kommt wieder darauf an. Wenn Sie über viele Millionen Datensätze verfügen und Verknüpfungen mit ihnen ausführen, ist es sinnvoll, die Suche nach etwas Trivialem (in eine materialisierte Ansicht) zu denormalisieren. Für alle praktischen Zwecke ist die relative Verbindungseffizienz auf einer modernen Maschine zwischen einem Schlüssel mit 5 Zeichen und einem Schlüssel mit variabler Länge so ähnlich, dass sie identisch ist. Glücklicherweise leben wir in einer Welt mit reichlich CPU und reichlich Festplatten. Die schlimmsten sind zu viele Verknüpfungen und ineffiziente Abfragen, anstatt Zeichen für Zeichen zu vergleichen. Mit dieser sagte, immer testen .

P & T-Dinge dieser Ebene sind so datenbankabhängig, dass Verallgemeinerungen äußerst schwierig sind. Erstellen Sie zwei Beispielmodelle der Datenbank, füllen Sie sie mit der geschätzten Anzahl von Datensätzen und ermitteln Sie dann, welches schneller ist. Nach meiner Erfahrung macht die Zeichenlänge keinen großen Unterschied im Vergleich zu guten Indizes, guten Speicherkonfigurationen und anderen wichtigen Elementen zur Leistungsoptimierung.

Ich denke, es gibt kein Problem mit der Leistung für selten geänderte Tabellen. Vielleicht haben Sie in Zukunft Probleme mit dem Design. Ich empfehle Ihnen, Geschäftsdaten wegen geschäftlicher Änderungen nicht als Primärschlüssel zu verwenden. Verwenden Sie einen zusätzlichen Primärschlüssel, um Tabellen in Ihrem Modell zu "verknüpfen". Jegliche geschäftlichen Änderungen wirken sich NICHT auf Tabellen aus, die mit dieser Tabelle zusammenhängen.

Die eigentliche Frage ist, ob die Leistung von DB-Abfragen für Ihre Anwendung überhaupt von Bedeutung ist (Datengröße). Wenn Ihre Abfrage Mikrosekunden in Anspruch nimmt, ist das Speichern einiger Mikrosekunden mithilfe von IntSchlüsseln den Preis für Lesbarkeit / Wartbarkeit nicht wert. Wenn Ihre Abfrage jedoch einige Minuten dauert, lohnt es sich möglicherweise, einige dieser Minuten zu speichern Int.

Im Folgenden wird erläutert, warum Ganzzahlen die Abfragezeit (in Prozent der gesamten Abfragezeit) verringern können. Die SkySpark-Gründer können dies jedoch besser erklären als ich . Vollständige Offenlegung, mein Arbeitgeber zahlt SkySpark eine Menge Geld für die Nutzung seiner Datenbank und ich versuche, etwas Besseres / Schnelleres zu bauen.

Wenn Sie über zahlreiche sequenzielle Daten (Protokolldateien, Zeitreihen, Analysen, Text- oder Sprachkorpora) verfügen, die Verknüpfungen (Beziehungen) zu einer Ihrer Nachschlagetabellen aufweisen, ist der Speicherplatz trotz @ für die Abfragegeschwindigkeit von entscheidender Bedeutung. Die korrekte Analyse von Ballsun-Stanton, wie billig Platz in US-Dollar ist. Da die meiste Abfragezeit (für sequenzielle Daten) für das Lesen der Festplatte aufgewendet wird, ist der Speicherplatz nicht zeitsparend (in Prozent der gesamten Abfragezeit). Sofern Ihre RDB nicht alle Fremdschlüssel (Schlüssel zu verwandten Datensätzen) automatisch und effizient komprimiert / dekomprimiert, möchten Sie, dass alle Ihre Schlüssel so Inteffizient wie möglich in Bezug auf Speicherplatz (und Lesegeschwindigkeit) pro Informationseinheit sind Inhalt (Entropie). Zu Ihrer Information MyISAM in MySql unterwirft EinschränkungenWas Sie mit komprimierten Datenzeilen tun können (schreibgeschützt) Mit anderen Worten: Automatisch inkrementierte Ganzzahlen werden aufgrund der geringen Mindestgrößenbeschränkung für die meisten DB-Ganzzahlfelder bereits so weit komprimiert, wie dies theoretisch möglich ist. Und diese Komprimierung kommt ohne:

1. Komprimierungs- / Dekomprimierungsstrafe für die Abfragezeit
2. Leseeinschränkung für die Abfragezeit der Festplatte
3. schreibgeschützt oder andere DB-Einschränkungen für komprimierte Datensätze oder Schlüssel

Es gibt einen Grund, warum beliebte, effiziente ORMs wie Django standardmäßig Ganzzahlen für PKs automatisch inkrementieren und warum andere SO-Fragen zu dem gleichen Ergebnis kommen.