Wie mögen Sie Ihre Primärschlüssel?

In eine ziemlich rege Diskussion in meinem team war ich zu denken, was die meisten Menschen gerne als Primärschlüssel. Wir hatten die folgenden Gruppen-

  1. Int/BigInt die autoincrement gut genug Primärschlüssel.
  2. Es sollte mindestens 3 Spalten, die den Primärschlüssel bilden.
  3. Id, GUID und lesbarer Datensatz-IDS sollten alle unterschiedlich behandelt werden.

Was ist der beste Ansatz für die PKs? Es wäre fantastisch, wenn Sie könnten, begründen Sie Ihre Meinung. Gibt es einen besseren Ansatz, die oben genannten?

EDIT: hat Jemand ein einfaches Beispiel/Algorithmus zu generieren lesbare Kennungen für Zeilen, skaliert gut?

InformationsquelleAutor der Frage | 

  1. 66

    Wenn du gehst zu tun, jede synchronisieren zwischen den Datenbanken, gelegentlich verbundene apps, dann sollten Sie das verwenden von GUIDs für Ihre Primärschlüssel. Es ist so eine Art Schmerz für das debugging, also abgesehen von diesem Fall Neige ich dazu, zu bleiben, um zu int, autoincrement.

    Autoincrement int-Werte sein sollten, Ihre Standard, und nicht mit Ihnen zu begründen.

    InformationsquelleAutor der Antwort Bramha Ghosh

  2. 53

    Ich sehe nicht, eine Antwort, die Punkte aus (was ich als) die wirklich wesentlichen Punkt - nämlich, dass eine primäre Schlüssel ist, was garantiert, dass Sie nicht zwei Einträge in der Tabelle für das gleiche real-world entity (als Modell in der Datenbank). Diese Beobachtung hilft, festzustellen, was sind gute und was sind schlechte Entscheidungen für Primärschlüssel.

    Beispielsweise in einer Tabelle der (US -) Staat Namen und codes, die entweder den Namen oder den code kann der primary key - bilden Sie zwei verschiedene Kandidaten-Schlüssel, und einer von Ihnen (in der Regel den kürzeren - code) gewählt wird als Primärschlüssel. In der Theorie der funktionalen Abhängigkeiten (und join-Abhängigkeiten - 1NF durch 5NF - es ist den Kandidaten-Schlüssel, entscheidend sind vielmehr als einen primären Schlüssel.

    Für ein Gegenbeispiel, menschliche Namen in der Regel eine schlechte Wahl für einen Primärschlüssel. Es gibt viele Menschen, die gehen durch die Namen "John Smith" oder einige andere ähnliche Namen; sogar die Vornamen berücksichtigt werden (denken Sie daran: nicht jeder hat eine - für Beispiel, ich weiß nicht), es gibt viel Spielraum für die Vervielfältigung. Folglich, Menschen, die keine Namen als Primärschlüssel. Sie erfinden künstliche Schlüssel wie der Social Security Number (SSN) oder die Personalnummer, und verwenden Sie zum benennen der einzelnen.

    Ideale Primärschlüssel ist kurz, einzigartig, unvergesslich, und natürlich. Diese Eigenschaften, Einzigartigkeit ist verpflichtend; die übrigen haben zu flex in Anbetracht der Einschränkungen der Daten aus der realen Welt.

    Wenn es um die Festlegung der Primärschlüssel in einer Tabelle, daher müssen Sie schauen, was die Tabelle darstellt. Was Satz oder Sätze von Spalte Werte in der Tabelle eindeutig identifiziert jede Zeile in der Tabelle? Das sind die Kandidaten-Schlüssel. Nun, wenn jeder Kandidat Schlüssel besteht aus 4 oder 5 Spalten, dann könnten Sie entscheiden, dass diejenigen, die sind zu ungeschickt, um einen guten Primärschlüssel (in Erster Linie wegen der Kürze). Unter diesen Umständen, könnten Sie sich vorstellen, ein Ersatzschlüssel - eine künstlich generierte Nummer. Sehr oft (aber nicht immer) ein einfacher 32-bit-integer reicht für den Ersatzschlüssel. Sie legen dieses Surrogat-Schlüssel als Primärschlüssel.

    Jedoch, Sie muss noch dafür sorgen, dass die anderen Kandidaten-Schlüssel (für den Ersatz-Schlüssel ist ein Kandidaten-Schlüssel, sowie auch, wie die gewählten Primärschlüssel) sind alle gepflegt, die als eindeutige Kennung - in der Regel, indem eine unique-Einschränkung auf jene Gruppen von Spalten.

    Manchmal, Menschen finden es schwierig, zu identifizieren, was macht eine Zeile eindeutig, aber es sollte etwas sein, das zu tun, weil einfach wiederholen, ein Stück von Informationen, ist es nicht mehr wahr. Und wenn Sie nicht vorsichtig sind und tun, erhalten Sie zwei (oder mehr) Zeilen, die angeblich speichern die gleichen Informationen, und Sie müssen dann, um die Informationen zu aktualisieren, es besteht die Gefahr (besonders wenn man mit dem Cursor), die Sie aktualisieren nur eine Zeile, anstatt in jeder Zeile, sodass die Zeilen sind aus der SYNCHRONIE und niemand weiß, welche Zeile die richtige Informationen enthält.

    Dies ist ein ziemlich schwer-line-Blick, in gewisser Hinsicht.

    Ich habe kein bestimmtes problem mit Hilfe einer GUID, wenn Sie gebraucht werden, aber Sie neigen dazu großen (wie in 16-64 bytes), und Sie werden zu oft verwendet. Sehr oft eine ganz gute 4-byte-Wert ausreichen würde. Mithilfe einer GUID, wo ein 4-byte-Wert würde genügen, belegen unnötig Speicherplatz und verlangsamt sogar den indizierten Zugriff auf die Daten, da es weniger Werte pro index-Seite, also die index wird tiefer und mehr Seiten zu Lesen, an die Informationen zu kommen.

    InformationsquelleAutor der Antwort Jonathan Leffler

  3. 22

    Dies ist nur eine religiöse Angelegenheit, weil die Menschen versuchen, eine Universelle richtige Antwort. Die Tatsache, dass sowohl Ihr team und dieses SO thread zeigt so viel Uneinigkeit sollte ein Hinweis darauf sein, dass es gute Gründe für die Verwendung von alle die Lösungen, die Sie beschreiben, in verschiedenen Situationen.

    • Ersatzschlüssel sind nützlich, wenn kein anderes Attribut oder ein Satz von Attributen in der Tabelle ist geeignet, um die Zeilen eindeutig identifizieren.
    • Natürliche Schlüssel sind am günstigsten, wenn möglich, um die Tabelle mehr lesbar sind. Natürliche Tasten erlauben auch den Fremdschlüssel in die abhängige Tabelle zu enthalten, die eine real-Wert anstelle eines Surrogat-id. E. g. wenn Sie brauchen, um zu speichern state (CA, TX, NY), Sie könnte genauso gut verwenden ein char(2) natürlichen Schlüssel anstelle eines int.
    • Verwenden compound primary keys, wo angebracht. Fügen Sie ein "id" Ersatzschlüssel unnötig, wenn eine gute compound-key vorhanden ist (dies ist insbesondere wahr in viele-zu-viele-Tabellen). Ein Mandat für ein drei-Säulen-key in jeder Tabelle ist absoluter Unsinn.
    • GUIDs sind eine Lösung, wenn Sie brauchen, um zu bewahren, Einzigartigkeit, die sich über mehrere Seiten. Sie sind auch praktisch, wenn Sie brauchen, die Werte im Primärschlüssel einzigartig sein, aber nicht bestellt oder konsekutiv.
    • INT vs. BIGINT: es ist nicht üblich, dass eine Tabelle erfordert eine 64-bit-Bereichs für die primäre Tasten, aber mit der zunehmenden Verfügbarkeit von 64-bit-hardware es sollte nicht eine Last sein, und gibt mehr Sicherheit, dass Sie nicht überlaufen. INT ist natürlich kleiner, so dass, wenn Raum an einer Prämie kann es geben einen leichten Vorteil.

    InformationsquelleAutor der Antwort

  4. 20

    Ich mag Die Datenbank-Programmierer blog als Quelle für diese Art von info.

    3 Spalten für die Primärschlüssel? Ich würde sagen, dass die Spalten sollten geeignete unique-Einschränkungen, wie die business-Regeln verlangen, aber ich würde noch eine separate Ersatzschlüssel. Verbundschlüssel meine business-Logik tritt in den Schlüssel. Wenn die Logik verpasst, Ihre ganze schema geschraubt.

    InformationsquelleAutor der Antwort

  5. 14

    Ich mag meine einzigartigen.

    InformationsquelleAutor der Antwort

  6. 9

    Gehe ich immer mit dem Ersatzschlüssel. Ein Ersatzschlüssel (in der Regel eine identity-Spalte autoincrement oder die GUID) ist eine, in der der Schlüssel nicht vorhanden ist, in den Daten selbst. Ein natürlicher Schlüssel, auf der anderen Seite, ist eine, die, auf seine eigene, der die Zeile eindeutig identifiziert. Als nahe als ich kann erzählen, im Leben, es gibt kaum real natürlichen Schlüssel. Nicht einmal Dinge wie SSN in den USA ist ein natürlicher Schlüssel. Composite primary keys sind eine Katastrophe warten, um zu geschehen. Sie können nicht ändern, dass die Daten (das ist der große Nachteil der natürlichen Schlüssel, composite oder nicht), aber noch schlimmer ist, dass mit einem zusammengesetzten Schlüssel, jetzt haben Sie zu verewigen, dass wichtige Daten in allen verbundenen Tabelle. Was für eine riesige Verschwendung.

    Nun, für die Auswahl der Ersatzschlüssel, halte ich mich mit identity-Spalten (ich arbeite meist in MS SQL-Server). GUID ' s zu groß sind, und Microsoft empfiehlt gegen Sie als PK. Wenn Sie mehrere Server haben, alle Sie tun müssen ist, stellen Sie die Schrittweite auf 10 oder 20 oder was auch immer Sie denken, dass die maximale Anzahl der Server, die Sie jemals brauchen werden, um sync - /ausbauen, und nur inc die Samen für jede Tabelle auf jeder nachfolgenden server, und Sie müssen nie wieder eine Daten-Kollision.

    Natürlich, weil die Schrittweite, habe ich die identity-Spalte eine BigInt - (sonst bekannt als long [64 bit]).

    Tut ein wenig Mathematik, selbst wenn Sie die Inkrement-100 können Sie immer noch 92,233,720,368,547,758 (> 92 Billiarden) Zeilen in der Tabelle.

    InformationsquelleAutor der Antwort

  7. 9

    Ich denke, die Verwendung des Wortes "Primär" in dem Satz "Haupt -" Schlüssel ist im eigentlichen Sinne irreführend.

    Verwenden Sie zuerst die definition, dass ein "Schlüssel" ist ein Attribut oder Menge von Attributen, müssen innerhalb der Tabelle eindeutig sein,

    Dann, nachdem eine beliebige Taste dient mehreren oft gegenseitig inkonsistent Zwecke.

    1. Zu verwenden, da schließt sich die Bedingungen zu einem oder mehreren Datensätzen in untergeordneten Tabellen, die eine Beziehung zu diesem übergeordneten Tabelle. (Explizit oder implizit die Definition eines Foreign Key in diejenigen, die den child-Tabellen)
    2. (Verwandte) Sicherzustellen, dass untergeordnete Datensätze müssen einen übergeordneten Datensatz in der übergeordneten Registerkarte;e (Die untergeordnete Tabelle FK bestehen muss als Schlüssel in der übergeordneten Tabelle)

    3. Erhöhen perforamce von Abfragen, die brauchen, um schnell zu lokalisieren einem bestimmten Datensatz/Zeile in der Tabelle.

    4. Um die Konsistenz der Daten sicherzustellen, indem verhindert doppelte Zeilen repräsentieren die gleiche logische Entität eingefügt itno den Tisch. (Dies wird Häufig als "Natürliche" - Taste, und sollte sich aus der Tabelle (Entität) Attribute, die relativ invariant.)

    Klar, alle nicht-aussagekräftige, nicht-Natürliche Schlüssel (wie eine GUID oder eine automatisch generierte ganze Zahl ist völlig unfähig, befriedigende #4.

    Aber oft, viele (die meisten) Tabellen, die eine völlig Natürliche Schlüssel, die #4 werden, bestehen oft aus mehreren Attributen und werden übermäßig breit oder so breit, dass Sie es für Zwecke #1, #2 oder #3 wird verursachen nicht akzeptable performance consequencecs.

    Die Antwort ist einfach. Beide verwenden. Verwenden Sie eine einfache, automatische Generierung von wesentlicher Schlüssel für alle verbindungen und FKs in anderen child-Tabellen aus, aber sorgen Sie dafür, dass jede Tabelle erfordert die Konsistenz der Daten (sehr wenige Tabellen nicht) eine Alternative Natürliche eindeutigen Schlüssel, der verhindert, dass Einsätze von inkonsistenten Daten Zeilen... Plus, wenn Sie immer beides haben, dann sind alle Einwände gegen die Verwendung von natürlichen Schlüssel (was, wenn es änderungen? Ich Wechsel jede Stelle verwiesen wird als FK) werden, strittig, als Sie es nicht verwenden... Sie sind nur in der einen Tabelle, wo es eine PK, zu vermeiden inkonsistent duplciate Daten...

    Als GUIDs, werden Sie sehr vorsichtig mit Ihnen, wie Sie das verwenden von guids in einem index können Schlauch-index-Fragmentierung. Die häufigsten algorithmen verwendet, um Sie zu erstellen stellt die "random" - Teil der guid in die meisten bit-Positionen... Dies erhöht die Anforderung für das regelmäßige index-Defragmentierung /- Reindexing, als neue Zeilen Hinzugefügt werden.

    InformationsquelleAutor der Antwort

  8. 8

    Eine Sache, die Sie nie tun sollten, ist eine smart-Taste. Das ist ein Schlüssel, wo Informationen über den Datensatz codiert, der Schlüssel selbst, und es wird schließlich Biss Sie.

    Arbeitete ich in einem Ort, wo der Primärschlüssel wurde die account-ID, die eine Kombination aus Buchstaben und zahlen. Ich erinnere mich an keine Einzelheiten, aber zum Beispiel die Konten, die waren einer bestimmten Art, wäre in der 600-Reihe und der anderen Art, startete mit 400. Das war toll, bis auf, dass der Kunde beschlossen, zu Fragen, die für beide Arten von Arbeit. Oder verändert die Art der Arbeit, die Sie getan haben.

    Anderer Stelle verwendet, den Speicherort in der Baumstruktur, die als Primärschlüssel für die Datensätze. So würde es Aufzeichnungen wie die folgenden.

    Cat1.subcatA.record1
Cat1.subcatA.record2
Cat1.subcatB.record1
Cat2.subcatA.record1

    Natürlich, das erste, was die Kunden wollten, war der Weg zum verschieben von Elementen im Baum herum. Der gesamte Satz von software, die starb, bevor das passiert ist.

    Bitte, bitte, bitte, wenn Sie code schreiben, den ich je erhalten haben, bitte don ' T verwenden ein smart-key!

    InformationsquelleAutor der Antwort

  9. 8

    Etwas off-topic, aber ich fühle mich verpflichtet zu erwähnen...

    Wenn Ihr Primärschlüssel ist eine GUID, nicht machen es zu einem gruppierten index. Da die GUIDs nicht sequentiell sind, werden die Daten neu geordnet und auf die Festplatte während fast jeder einfügen. (Igitt.) Wenn Sie das verwenden von GUIDs als Primärschlüssel, sollten Sie nicht gruppierte Indizes.

    InformationsquelleAutor der Antwort

  10. 4

    Ich bin ein fan von der auto-Inkrement als Primärschlüssel. Ich weiß, tief in meinem Herzen, dass dies ist ein cop-out, aber es macht es so einfach, um Daten zu Sortieren, wenn es Hinzugefügt wird (ORDER BY ID DESC, f ' r Instanz).

    3 Spalten klingt furchtbar hart, um menschlich zu analysieren.

    - Und das ist der trade-off-wie viel die relationalen Fähigkeiten brauchen Sie, versus und DIESE TABELLE HIER RICHTIG verständlich für einen Menschen befragen, die es (im Vergleich zu den gespeicherten Prozedur oder eine programmierbare Schnittstelle).

    auto-increment ist für uns Menschen. 🙁

    InformationsquelleAutor der Antwort Michael Paulukonis

  11. 4

    In der Regel, es hängt davon ab.

    Persönlich, ich mag autoincrement int.

    Aber, eins kann ich Ihnen sagen, ist es nie Vertrauen Sie Daten aus anderen Quellen als Ihr Schlüssel. Ich schwöre, jedes mal, wenn ich getan habe, dass es zurück kommt, mich zu beissen. Gut, nie wieder!

    InformationsquelleAutor der Antwort BoltBait

  12. 3

    Sollte es mindestens 3 Spalten, die den Primärschlüssel bilden.

    Ich verstehe das nicht.

    Sprechen Sie von einem "natürlichen Schlüssel", z.B. "name und Geburtsdatum"? Ein natürlicher Schlüssel sein könnte ideal für Sie, wenn es vorhanden ist, aber die meisten Kandidaten für einen natürlichen Schlüssel sind entweder nicht eindeutig (mehrere Personen mit dem gleichen Namen) oder nicht konstant (kann sich jemand ändern Ihren Namen).

    Int/BigInt die autoincrement gut genug Primärschlüssel.

    Ich lieber Guid. Ein mögliches problem mit autoincrement ist, dass der Wert (z.B. "order-id") zugeordnet ist, von der Datenbank-Instanz (z.B. durch die "sales-Datenbank") ... das wird nicht ganz funktionieren (stattdessen starten zu müssen zusammengesetzten Schlüssel), wenn Sie jemals brauchen werden, um Zusammenführen von Daten erstellt, die von mehr als einer Datenbank-Instanz (z.B. aus mehreren Vertriebsbüros, jede mit Ihrer eigenen Datenbank).

    InformationsquelleAutor der Antwort ChrisW

  13. 3

    RE GUID

    Watch out, wenn er einen wirklich Wirklich WIRKLICH WIRKLICH große Datenbank, viel Last, und schnellen Zugriff.

    Bei meinem letzten job, wo wir Datenbanken von 100 bis 500 Millionen Datensätze, die unsere Datenbank Jungs stark argumentiert gegen GUIDs, und für eine entsprechend dimensionierte Dezimalzahl. Sie fühlten, dass (unter Oracle) die Größe der Differenz in den internen Speicher für einen string Guid - vs - dezimal-Wert würde einen sehr spürbaren Unterschied in lookups. ( Größere Tasten = tiefere Bäume zu durchqueren)

    Die zufällige Natur von GUIDs, auch reduziert sich der Füllfaktor für den index-Seiten deutlich - dies erhöht drastisch reißen und disk-I/O.

    InformationsquelleAutor der Antwort

  14. 2

    Auto increment-Spalten. Ich bin in der Lage, mein code funktioniert nahtlos mit SQL Server oder Oracle, die eine Identität mit dem anderen, indem Sie Sequenzen durch meine DAL, und ich könnte nicht glücklicher sein. Ich bin damit einverstanden, GUIDs sind manchmal notwendig, wenn Sie tun, Replikation oder senden von Daten zu empfangen, die es später nach der Verarbeitung.

    InformationsquelleAutor der Antwort

  15. 2

    Benutzte ich immer einen Ersatzschlüssel - ein autoincrementing integer namens 'id'. Ich sehe viele Gründe, dies zu tun, auch wenn eine andere option ist offensichtlich:

    • Konsistenz
    • Daten unabhängigen (einzigartig, nicht zerstört werden durch änderungen an format)
    • Lesbare

    ...und keinen sinnvollen Grund, nicht zu: Sie

    • Mehrdeutigkeit in Verknüpfungen? - Alias-Tabellen ist eine bessere Praxis, IMHO
    • Optimale Tabellen? - Entfernen von einem byte pro Eintrag ist die vorzeitige Optimierung, IMHO
    • Pro-Tisch-Entscheidung? - Nicht mehr konsistent
    • Skalierung Probleme? - Eh? Warum?
    • Hierarchische Daten-Struktur? - Das ist denormalising, ein ganz anderes Thema religion. Es genügt zu sagen, ich bin ein fan in ein paar Umstände, die in der Theorie, aber nie in der Praxis 🙂

    vernünftige Gründe vor, die ich noch nicht gedacht, oder kommen auf und sind doch immer willkommen...

    InformationsquelleAutor der Antwort

  16. 1

    Dies ist ein klassisches "es hängt". Es gibt nicht die eine richtige Antwort für jedes Projekt. Ich mag verschiedene Dinge für verschiedene Situationen. Es hängt davon ab, ob ich mit einem ORM und was es unterstützt. Es hängt von der Gesamt-Architektur (verteilte oder nicht, etc). Wählen Sie einfach eine, die Sie denken, arbeiten und bewegen auf zu streiten über tabs und Leerzeichen.

    InformationsquelleAutor der Antwort

  17. 1

    Ich Neige dazu, verwenden Sie die option #1 oder #3 abhängig von der Größe, der Anzahl der Menschen verbinden, und ob es ein mehrere Datenbank-server-situation ist oder nicht.

    Option #2 macht nicht viel Sinn für mich. Wenn einer der drei ist nicht genug, um einen eindeutigen Datensatz, dann ist es möglich (ohne Umweg über zusätzliche Machenschaften) zwei haben zwei Datensätze mit den gleichen Werten in allen drei Spalten. Wenn Sie wollen Eindeutigkeit, jede beliebige Kombination der drei, dann fügen Sie nur einen index für Sie.

    InformationsquelleAutor der Antwort BIBD

  18. 1

    Habe ich nur eine auto-increment-int oder eine GUID. 99% der Zeit, die ich habe, verwenden Sie auto-increment int. Es ist genau das, was ich gelehrt wurde, zu verwenden, wenn ich zum ersten mal gelernt, Datenbanken und haben noch nie ein Grund, Sie nicht zu verwenden (obwohl ich weiß, der Gründe, warum eine GUID wäre besser).

    Ich, wie das auto-Inkrement-ints, weil es hilft bei der Lesbarkeit. Zum Beispiel kann ich sagen: "werfen Sie einen Blick auf record 129383" und es ist ziemlich einfach für jemanden zu gehen und ihn zu finden. Mit einem GUID das ist fast unmöglich zu tun.

    InformationsquelleAutor der Antwort

  19. 1

    Vergangenheit eine grundlegende definitorische Antwort, was ist ein gute primary key übrig ist, weitgehend zu religion und Pausenraum Argumente. Wenn Sie etwas haben, das ist und wird immer, die Karte eindeutig zu einer einzelnen Zeile, dann wird es funktionieren als Primärschlüssel. Der Vergangenheit, die zeigen, es gibt auch andere überlegungen:

    • Ist der primary key-definition nicht zu Komplex? Tut es vermeiden eine unnötige Komplexität für den Willen nach einer "best-practice"?
    • Gibt es eine bessere möglich Primärschlüssel, der erforderlich wäre, weniger overhead für die Datenbank zu verarbeiten (z.B. INTEGER vs. VARCHAR, etc)?
    • Bin ich ABSOLUT sicher, dass die Einzigartigkeit und definiert-ness-invariante von mein primary key wird sich nicht ändern?

    Diese Letzte ist wahrscheinlich das, was zieht die meisten Menschen verwenden Dinge wie GUIDs oder self-increment-integer-Spalten, weil sich auf Dinge wie Adressen, Telefonnummern, Vornamen, Namen, etc, einfach nicht schneiden es. Die einzige invariante über Leute, die ich denken kann, ist Sozialversicherungsnummern, aber dann bin ich auch nicht 100% sicher über die verbleibenden für immer einzigartig.

    Hoffentlich hilft fügen Sie einige Klarheit...

    InformationsquelleAutor der Antwort Ed Carrel

  20. 1

    Den Umgang mit primary keys (und meiner Meinung nach ist die beste) ist zu vermeiden, dass ein "default" - Ansatz. Dies bedeutet, dass statt nur slapping auf einer auto-increment-integer und nannte es einen Tag schaue ich mir das problem an und sagen "da ist eine Spalte oder Gruppe von Spalten, die immer unqiue und wird sich nicht ändern?" Wenn die Antwort ja ist, dann nehme ich diesen Ansatz.

    InformationsquelleAutor der Antwort

  21. 1

    Fast immer zahlen.

    Haben Sie andere gute Gründe, abgesehen davon, dass kleiner/schneller zu verarbeiten. Was würden Sie lieber schreiben - "404040" oder "3463b5a2-a02b-4fd4-aa0f-1d3c0450026c"?

    InformationsquelleAutor der Antwort

  22. 1

    Nur geringfügig relevant, aber eine Sache, ich habe damit angefangen vor kurzem, als ich klein Klassifizierung Tabellen (im wesentlichen diejenigen, die darstellen würde ENUMs im code) ist, dass ich mache den primary key ein char(3) char(4). Dann mache ich die primäre Schlüssel Vertreter der lookup-Wert.

    Ich habe zum Beispiel ein quoting-system für unsere interne Sales Agents. Wir haben "Kostenkategorien", dass jedes Zitat werbebuchung zugewiesen wird... So habe ich eine Art lookup-Tabelle namens "tCostCategories', wo der Primärschlüssel ist 'MTL', 'SVC', 'TRV', 'STEUER', 'ODC'. In anderen Spalten der Nachschlagetabelle zu speichern sind, mehr details, wie das normale englische Bedeutungen der codes, "Material", "Service", "Reisen", "Steuern", "Sonstige Direkte Kosten", und so weiter.

    Ist das wirklich schön, weil es nicht mehr Platz als ein int, und wenn Sie sind suchen an der Quelle der Daten, die Sie nicht haben, um die Verbindung der lookup-Tabelle, um zu wissen, was zum Teufel das Wert ist. Zum Beispiel, ein Zitat, Zeile Aussehen könnte:

    1 Bauteilnummer $40 MTL

    2 OtherPartNumber $29.99 SVC

    3 PartNumber2 $150 TRV

    Ist es viel einfacher, mit einem int darstellen, die Kategorien und dann die Verknüpfung 1, 2, 3, auf allen Linien - Sie haben die Daten direkt dort vor Ihnen, und die Leistung scheint nicht betroffen (nicht, dass ich ' ve wirklich getestet.)

    Soweit die eigentliche Frage geht... ich mag die RowGUID-uniqueidentifiers. Ich bin mir nicht 100%, aber nicht alle Zeilen der internen RowGuid ' s überhaupt?? Wenn dem so ist, dann über die RowGuid würde tatsächlich nehmen weniger Platz als int-Werte (oder irgendetwas anderes für diese Angelegenheit.) Alles was ich weiß ist, dass wenn es gut genug für M$ zur Verwendung in GreatPlains, dann ist es gut genug für mich. (Sollte ich Ente??)

    InformationsquelleAutor der Antwort

  23. 1

    Oh man, ein Grund mehr, die ich verwende GUIDs - ich habe eine hierarchische Datenstruktur. Das heißt, ich habe eine Tabelle 'Firma' und eine Tabelle 'Verkäufer', für die die Primärschlüssel übereinstimmen. Ich habe aber auch eine Tabelle 'Hersteller' , auch 'erbt' von Unternehmen. Die Felder, die üblich sind, die die Hersteller und Hersteller nicht in die Tabellen - Sie erscheinen in der Firma. In diesem setup, mit int ist viel schmerzhafter als Guids. Zumindest können Sie nicht verwenden, identity primary keys.

    InformationsquelleAutor der Antwort

  24. 1

    Ich mag Natürliche Schlüssel, wenn ich Ihnen Vertrauen können. Ich bin bereit zu zahlen eine geringe Leistung Preis Preis in Reihenfolge zu benutzen Sie die Tasten, die Sinn machen für die Fachexperten.

    Für Tabellen, die beschreiben Entitäten, es sollte eine einfache und Natürliche Schlüssel, identifiziert den einzelnen Instanzen der gleichen Weise den Gegenstand, die Menschen tun. Wenn der Gegenstand nicht vertrauenswürdig Bezeichner für eines der Unternehmen, dann werde ich in dem resort einen Ersatzschlüssel.

    Für Tabellen beschreiben die Beziehungen, die ich verwenden einen zusammengesetzten Schlüssel, wobei jede Komponente mit Verweis auf eine Entität, die Teil in der Beziehung, und daher eine Zeile in einer Entität Tabelle. Wieder, der Leistungseinbruch bei Verwendung eines zusammengesetzten Schlüssel ist in der Regel minimal.

    Als andere haben darauf hingewiesen, dass der Begriff "primary key" ist ein wenig irreführend. In das Relationale Datenmodell, der Begriff, der verwendet wird, ist "candidate keys". Es könnte mehrere candidate keys für eine einzelne Tabelle. Logisch, jeder ist nur so gut wie der andere. Die Wahl einer von Ihnen als "primary" und bei allen Referenzen über diesen Schlüssel, ist einfach eine Wahl, die der designer machen kann.

    InformationsquelleAutor der Antwort

  25. 1

    Guids.Zeitraum.

    In der Veranstaltung, die Sie brauchen, um zu skalieren oder weisen Sie den Primärschlüssel von alternativen bedeutet, Sie wird dein Freund sein. Sie können hinzufügen von Indizes für alles andere.

    update zu verdeutlichen meine Aussage.

    Ich gearbeitet habe, auf eine Menge von verschiedenen Arten von Websites. Von kleinen single-server-Angebote zu großen Unternehmen unterstützt mit mehreren DB-und web-Servern. Es wurden sicherlich apps, die hätte Sie einfach nur gut mit auto increment int-Werten als Primärschlüssel. Diejenigen allerdings, die passen nicht in das Modell, wie ich Dinge tun.

    Wenn Sie mithilfe einer GUID, die Sie erzeugen kann die ID überall. Es konnte generiert werden, die von einem remote-server, auf Ihrem web-app, in der Datenbank selbst oder auch innerhalb mehrerer Datenbanken in einer multimaster-situation.

    Auf der anderen Seite, ein auto inkrementiert INT kann nur sicher erzeugt in der primären Datenbank. Wieder, dies könnte okay, wenn Sie eine Anwendung haben, die werden eng gebunden, dass man die backing-DB-server und die Skalierung ist nicht etwas, was Sie besorgt sind.

    Sicher, dass die Verwendung von GUIDs bedeuten, dass Sie haben, um abends Neuindizierung Prozesse. Allerdings, wenn Sie etwas anderes als ein auto inkrementiert INT sollten Sie tun, sowieso. Was solls, mit einem INT als primär ist es wahrscheinlich, Sie haben andere Indizes, die müssen regeneriert Umgang mit Fragmentierung. Daher ist die Verwendung von GUIDs nicht genau, fügen Sie ein weiteres problem, denn diese Aufgaben müssen durchgeführt werden, unabhängig.

    Wenn man einen Blick auf die größeren apps gibt, die Sie werden feststellen, etwas wichtiges: Sie alle verwenden Sie Base64-codiert GUIDs als Schlüssel. Der Grund dafür ist einfach, die Verwendung von GUIDs können Sie skalieren aus einfach in der Erwägung, dass es gibt eine Menge von Reifen zu springen durch, wenn Sie versuchen zu skalieren mit Int-Werten.

    Unsere neueste app geht über einen Zeitraum von schweren Einsätzen, dauert etwa einen Monat. Nach, dass 90+% der Abfragen werden alle wählt für die Berichterstattung. Um die Kapazität zu erhöhen kann ich zusätzliche DB-Server während dieses große insert-Periode; und später einfach Zusammenführen, die in einen einzigen DB für die Berichterstattung. Der Versuch zu tun, die mit Int-Werten wäre ein absoluter Albtraum.

    Ganz ehrlich, jedes mal, wenn Ihr cluster eine Datenbank-oder setup-Replikation der DB-server verlangen, dass Sie GUIDs auf die Tabelle sowieso. Also, wenn Sie denken, dass Ihr system möglicherweise zum wachsen brauchen, dann wählen Sie die, die ist gut.

    InformationsquelleAutor der Antwort

  26. 0

    Dies ist ein Komplexes Thema, ob man es realisiert oder nicht. Vielleicht fallen unter den Abschnitt auf dieser StackOverflow-FAQ.

    Welche Art von Fragen sollte ich nicht hier Fragen?

    Vermeiden, Fragen zu stellen, die subjektiven, argumentativen, oder erfordern eine erweiterte Diskussion. Dies ist ein Ort für Fragen, die beantwortet werden können!

    Diese wurde diskutiert seit Jahren und wird auch weiterhin diskutiert werden für die Jahre. Die einzigen Hinweise von Konsens, die ich gesehen habe ist, dass die Antworten vorhersehbar, je nachdem, wenn Sie Sie bitten, einen OO-Typ (GUIDs sind der einzige Weg zu gehen!), ein data modeler (untertasten sind der einzige Weg zu gehen!), oder ein performance-orientierten DBA (INTs sind der einzige Weg zu gehen!).

    InformationsquelleAutor der Antwort

Schreibe einen Kommentar