Wie gefallen Ihnen Ihre Primärschlüssel? [geschlossen]

In einer ziemlich lebhaften Diskussion in meinem Team wurde ich dazu gebracht zu überlegen, was die meisten Leute als Primärschlüssel mögen. Wir hatten die folgenden Gruppen-

1. Int / BigInt welche Autoincrement sind gut genug Primärschlüssel.
2. Es sollten mindestens 3 Spalten vorhanden sein, aus denen der Primärschlüssel besteht.
3. ID-, GUID- und von Menschen lesbare Zeilenbezeichner sollten alle unterschiedlich behandelt werden.

Was ist der beste Ansatz für PKs? Es wäre großartig, wenn Sie Ihre Meinung rechtfertigen könnten. Gibt es einen besseren Ansatz als den oben genannten?

BEARBEITEN: Hat jemand ein einfaches Beispiel / einen einfachen Algorithmus, um lesbare Bezeichner für Zeilen zu generieren, die gut skaliert werden können?

Wenn Sie eine Synchronisierung zwischen Datenbanken mit gelegentlich verbundenen Apps durchführen möchten, sollten Sie GUIDs für Ihre Primärschlüssel verwenden. Es ist eine Art Schmerz beim Debuggen, also neige ich, abgesehen von diesem Fall, dazu, mich an Ints zu halten, die automatisch erhöht werden.

Autoincrement Ints sollte Ihr Standard sein, und nicht sie gerechtfertigt verwenden sollten.

Ich sehe keine Antwort, die auf den wirklich grundlegenden Punkt hinweist (was ich als solchen betrachte) - nämlich, dass ein Primärschlüssel garantiert, dass Sie nicht zwei Einträge in der Tabelle für dieselbe reale Entität erhalten (as in der Datenbank modelliert). Diese Beobachtung hilft festzustellen, was gute und was schlechte Entscheidungen für den Primärschlüssel sind.

Beispielsweise könnte in einer Tabelle mit (US-) Statusnamen und -codes entweder der Name oder der Code der Primärschlüssel sein - sie bilden zwei verschiedene Kandidatenschlüssel, und einer von ihnen (normalerweise der kürzere - der Code) wird als der ausgewählt Primärschlüssel. In der Theorie der funktionalen Abhängigkeiten (und der Verknüpfungsabhängigkeiten - 1NF bis 5NF - sind die Kandidatenschlüssel entscheidend und nicht ein Primärschlüssel.

Als Gegenbeispiel treffen menschliche Namen im Allgemeinen eine schlechte Wahl für den Primärschlüssel. Es gibt viele Leute, die den Namen "John Smith" oder ähnliche Namen tragen; Selbst wenn man den zweiten Vornamen berücksichtigt (denken Sie daran: Nicht jeder hat einen - zum Beispiel nicht ich), gibt es viel Spielraum für Vervielfältigungen. Folglich verwenden Personen keine Namen als Primärschlüssel. Sie erfinden künstliche Schlüssel wie die Sozialversicherungsnummer (SSN) oder die Mitarbeiternummer und verwenden sie zur Bezeichnung der Person.

Ein idealer Primärschlüssel ist kurz, einzigartig, einprägsam und natürlich. Von diesen Merkmalen ist die Eindeutigkeit obligatorisch; Der Rest muss sich angesichts der Einschränkungen der Daten der realen Welt biegen.

Wenn Sie den Primärschlüssel einer bestimmten Tabelle bestimmen möchten, müssen Sie sich daher ansehen, was diese Tabelle darstellt. Welche Menge oder Sätze von Spaltenwerten in der Tabelle identifiziert jede Zeile in der Tabelle eindeutig? Das sind die Kandidatenschlüssel. Wenn jeder Kandidatenschlüssel aus 4 oder 5 Spalten besteht, können Sie entscheiden, dass diese zu ungeschickt sind, um einen guten Primärschlüssel zu erstellen (hauptsächlich aus Gründen der Kürze). Unter diesen Umständen können Sie einen Ersatzschlüssel einführen - eine künstlich generierte Zahl. Sehr oft (aber nicht immer) reicht eine einfache 32-Bit-Ganzzahl für den Ersatzschlüssel aus. Anschließend legen Sie diesen Ersatzschlüssel als Primärschlüssel fest.

Sie müssen jedoch weiterhin sicherstellen, dass die anderen Kandidatenschlüssel (denn der Ersatzschlüssel ist auch ein Kandidatenschlüssel sowie der ausgewählte Primärschlüssel) alle als eindeutige Kennung beibehalten werden - normalerweise, indem Sie diesen Spaltengruppen eine eindeutige Einschränkung auferlegen.

Manchmal fällt es den Leuten schwer zu identifizieren, was eine Zeile einzigartig macht, aber es sollte etwas zu tun geben, weil das einfache Wiederholen einer Information sie nicht mehr wahr macht. Und wenn Sie nicht aufpassen und zwei (oder mehr) Zeilen erhalten, die angeblich dieselben Informationen speichern, und Sie dann die Informationen aktualisieren müssen, besteht die Gefahr (insbesondere wenn Sie Cursor verwenden), dass Sie nur eine Zeile aktualisieren anstatt jeder Zeile, daher sind die Zeilen nicht synchron und niemand weiß, welche Zeile die richtigen Informationen enthält.

Dies ist in mancher Hinsicht eine ziemlich harte Sichtweise.

Ich habe kein besonderes Problem mit der Verwendung einer GUID, wenn sie benötigt werden, aber sie sind in der Regel groß (wie in 16-64 Bytes) und werden zu oft verwendet. Sehr oft würde ein perfekter 4-Byte-Wert ausreichen. Die Verwendung einer GUID, bei der ein 4-Byte-Wert ausreichen würde, verschwendet Speicherplatz und verlangsamt sogar den indizierten Zugriff auf die Daten, da weniger Werte pro Indexseite vorhanden sind, sodass der Index tiefer ist und mehr Seiten gelesen werden müssen, um zum zu gelangen Information.

Dies ist nur eine religiöse Angelegenheit, weil die Menschen eine universelle richtige Antwort suchen. Die Tatsache, dass sowohl Ihr Team als auch dieser SO-Thread so viele Meinungsverschiedenheiten aufweisen, sollte ein Hinweis darauf sein, dass es gute Gründe gibt, alle von Ihnen beschriebenen Lösungen unter verschiedenen Umständen zu verwenden.

• Ersatzschlüssel sind nützlich, wenn kein anderes Attribut oder Satz von Attributen in der Tabelle geeignet ist, Zeilen eindeutig zu identifizieren.
• Wenn möglich, werden natürliche Schlüssel bevorzugt, um die Tabelle besser lesbar zu machen. Mit natürlichen Schlüsseln kann der Fremdschlüssel in einer abhängigen Tabelle auch einen realen Wert anstelle einer Ersatz-ID enthalten. Wenn Sie beispielsweise speichern müssen state(CA, TX, NY), können Sie auch einen char(2)natürlichen Schlüssel anstelle eines int verwenden.
• Verwenden Sie gegebenenfalls zusammengesetzte Primärschlüssel. Fügen Sie nicht idunnötig einen " " Ersatzschlüssel hinzu, wenn ein einwandfreier zusammengesetzter Schlüssel vorhanden ist (dies gilt insbesondere für viele-zu-viele-Tabellen). Ein Mandat für einen dreispaltigen Schlüssel in jeder Tabelle ist absoluter Unsinn.
• GUIDs sind eine Lösung, wenn Sie die Eindeutigkeit über mehrere Sites hinweg bewahren müssen. Sie sind auch nützlich, wenn Sie Werte im Primärschlüssel benötigen, die eindeutig, aber nicht geordnet oder fortlaufend sind.
• INT vs. BIGINT: Es ist nicht üblich, dass eine Tabelle einen 64-Bit-Bereich für Primärschlüssel benötigt. Mit der zunehmenden Verfügbarkeit von 64-Bit-Hardware sollte dies jedoch keine Belastung darstellen und bietet mehr Sicherheit, dass Sie nicht überlaufen. INT ist natürlich kleiner. Wenn also wenig Platz zur Verfügung steht, kann dies einen leichten Vorteil bringen.

Ich mag den Blog von The Database Programmer als Quelle für diese Art von Informationen.

3 Spalten für einen Primärschlüssel? Ich würde sagen, dass Spalten angemessene eindeutige Einschränkungen haben sollten, wie es die Geschäftsregeln erfordern, aber ich hätte immer noch einen separaten Ersatzschlüssel. Zusammengesetzte Schlüssel bedeuten, dass Geschäftslogik in den Schlüssel eingeht. Wenn sich die Logik ändert, wird Ihr gesamtes Schema verschraubt.

Ich mag meine einzigartig.

Etwas abseits des Themas, aber ich fühle mich gezwungen, mit ...

Wenn Ihr Primärschlüssel eine GUID ist, machen Sie ihn nicht zu einem Clustered-Index . Da GUIDs nicht sequentiell sind, werden die Daten bei fast jeder Einfügung auf der Festplatte neu angeordnet. (Yuck.) Wenn Sie GUIDs als Primärschlüssel verwenden, sollten diese nicht gruppierte Indizes sein.

Ich gehe immer mit dem Ersatzschlüssel. Ein Ersatzschlüssel (normalerweise eine Identitätsspalte, eine automatische Inkrementierung oder eine GUID) ist einer, in dem der Schlüssel nicht in den Daten selbst vorhanden ist. Ein natürlicher Schlüssel hingegen ist einer, der die Zeile für sich allein eindeutig identifiziert. Soweit ich das beurteilen kann, gibt es kaum welche echte natürliche Schlüssel. Nicht einmal Dinge wie SSN in den Vereinigten Staaten sind ein natürlicher Schlüssel. Zusammengesetzte Primärschlüssel sind eine Katastrophe, die darauf wartet, passiert zu werden. Sie können keine dieser Daten bearbeiten (was der Hauptnachteil eines natürlichen Schlüssels ist, ob zusammengesetzt oder nicht), aber schlimmer ist, dass Sie bei einem zusammengesetzten Schlüssel diese Schlüsseldaten jetzt in jeder zugehörigen Tabelle beibehalten müssen. Was für eine riesige Verschwendung.

Bei der Auswahl des Ersatzschlüssels bleibe ich bei den Identitätsspalten (ich arbeite hauptsächlich in MS SQL Server). GUIDs sind zu groß und Microsoft empfiehlt dagegen sie als PK verwenden. Wenn Sie mehrere Server haben, müssen Sie nur das Inkrement 10 oder 20 oder was auch immer Sie für die maximale Anzahl von Servern halten, auf die Sie jemals synchronisieren / erweitern müssen, und nur den Startwert für jede Tabelle auf jedem nachfolgenden Server einfügen und Sie werden nie eine Datenkollision haben.

Aufgrund des Inkrements mache ich die Identitätsspalte natürlich zu einem BigInt (auch bekannt als long [64 Bit]).

Wenn Sie ein bisschen rechnen, können Sie auch dann 92.233.720.368.547.758 (> 92 Billiarden) Zeilen in Ihrer Tabelle haben, wenn Sie das Inkrement 100 machen.

Ich denke, die Verwendung des Wortes "Primär" in der Phrase "Primärschlüssel" ist im wahrsten Sinne des Wortes irreführend.

Verwenden Sie zunächst die Definition, dass ein "Schlüssel" ein Attribut oder eine Reihe von Attributen ist, die innerhalb der Tabelle eindeutig sein müssen.

Dann dient ein Schlüssel mehreren oft inkonsistenten Zwecken.

1. Verwendung als Verknüpfungsbedingungen für einen oder mehrere Datensätze in untergeordneten Tabellen, die eine Beziehung zu dieser übergeordneten Tabelle haben. (Explizites oder implizites Definieren eines Fremdschlüssels in diesen untergeordneten Tabellen)
2. (verwandt) Sicherstellen, dass untergeordnete Datensätze einen übergeordneten Datensatz auf der übergeordneten Registerkarte haben müssen; e (Die untergeordnete Tabelle FK muss als Schlüssel in der übergeordneten Tabelle vorhanden sein.)

3. So erhöhen Sie die Leistung von Abfragen, bei denen ein bestimmter Datensatz / eine bestimmte Zeile in der Tabelle schnell gefunden werden muss.

4. So stellen Sie die Datenkonsistenz sicher, indem verhindert wird, dass doppelte Zeilen, die dieselbe logische Entität darstellen, in die Tabelle eingefügt werden. (Dies wird oft als "natürlicher" Schlüssel bezeichnet und sollte aus Tabellenattributen (Entitätsattributen) bestehen, die relativ unveränderlich sind.)

Es ist klar, dass jeder nicht aussagekräftige, nicht natürliche Schlüssel (wie eine GUID oder eine automatisch generierte Ganzzahl) nicht in der Lage ist, # 4 zu erfüllen.

Bei vielen (den meisten) Tabellen besteht ein völlig natürlicher Schlüssel, der # 4 bereitstellen kann, häufig aus mehreren Attributen und ist zu breit oder so breit, dass die Verwendung für die Zwecke # 1, # 2 oder # 3 inakzeptabel ist Leistungsfolgen

Die Antwort ist einfach. Verwende beide. Verwenden Sie einen einfachen Integralschlüssel mit automatischer Generierung für alle Joins und FKs in anderen untergeordneten Tabellen. Stellen Sie jedoch sicher, dass jede Tabelle, die Datenkonsistenz erfordert (nur sehr wenige Tabellen nicht), über einen alternativen natürlichen eindeutigen Schlüssel verfügt, der das Einfügen inkonsistenter Datenzeilen verhindert. .. Und wenn Sie immer beides haben, werden alle Einwände gegen die Verwendung eines natürlichen Schlüssels (was ist, wenn er sich ändert? Ich muss jeden Ort ändern, auf den er als FK verwiesen wird) streitig, da Sie ihn dafür nicht verwenden. .. Sie verwenden es nur in der einen Tabelle, in der es sich um eine PK handelt, um inkonsistente doppelte Daten zu vermeiden ...

Seien Sie bei GUIDs sehr vorsichtig, da die Verwendung von Guids in einem Index die Indexfragmentierung beeinträchtigen kann. Die gebräuchlichsten Algorithmen, mit denen sie erstellt werden, setzen den "zufälligen" Teil der Guid in die höchstwertigen Bitpositionen ... Dies erhöht die Anforderung für eine regelmäßige Indexdefragmentierung / Neuindizierung, wenn neue Zeilen hinzugefügt werden.

Eine Sache, die Sie niemals tun sollten, ist die Verwendung eines Smart Keys. Dies ist ein Schlüssel, bei dem Informationen über den Datensatz im Schlüssel selbst codiert sind und Sie schließlich beißen.

Ich habe an einem Ort gearbeitet, an dem der Hauptschlüssel die Konto-ID war, eine Kombination aus Buchstaben und Zahlen. Ich erinnere mich an keine Einzelheiten, aber zum Beispiel lagen die Konten eines bestimmten Typs im Bereich von 600 und eines anderen Typs mit 400. Das war großartig, bis dieser Kunde sich entschied, nach beiden zu fragen Arten von Arbeit. Oder die Art der Arbeit geändert, die sie getan haben.

An einem anderen Ort wurde der Ort im Baum als Primärschlüssel für Datensätze verwendet. Es würde also Aufzeichnungen wie die folgenden geben.

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

Das erste, was die Kunden wollten, war natürlich eine Möglichkeit, Elemente im Baum zu verschieben. Die gesamte Software ist zuvor gestorben.

Bitte, bitte, bitte, wenn Sie Code schreiben, den ich jemals pflegen muss, verwenden Sie bitte keinen Smart Key!

Ich bin ein Fan der automatischen Inkrementierung als Primärschlüssel. Ich weiß tief in meinem Herzen, dass dies ein Cop-out ist, aber es macht es so einfach, Daten nach dem Zeitpunkt des Hinzufügens zu sortieren (ORDER BY ID DESC, zum Beispiel).

3 Spalten klingen für die menschliche Analyse furchtbar hart.

Und das ist der Kompromiss - wie viel von der relationalen Fähigkeit benötigen Sie, um DIESE TABELLE HIER für einen Menschen verständlich zu machen, der sie abfragt (gegenüber der gespeicherten Prozedur oder der programmatischen Schnittstelle).

Auto-Inkrement ist für uns Menschen. :-(

Im Allgemeinen kommt es darauf an.

Persönlich mag ich Autoincrement Ints.

Aber eine Sache, die ich Ihnen sagen kann, ist, niemals Daten aus anderen Quellen als Ihren Schlüssel zu vertrauen. Ich schwöre, jedes Mal, wenn ich das getan habe, kommt es zurück, um mich zu beißen. Nie wieder!

Es sollten mindestens 3 Spalten vorhanden sein, aus denen der Primärschlüssel besteht.

Ich verstehe das nicht

Sprechen Sie über einen "natürlichen Schlüssel", zB "Name und Geburtsdatum"? Ein natürlicher Schlüssel ist möglicherweise ideal, wenn er vorhanden ist, aber die meisten Kandidaten für einen natürlichen Schlüssel sind entweder nicht eindeutig (mehrere Personen mit demselben Namen) oder nicht konstant (jemand kann seinen Namen ändern).

Int / BigInt welche Autoincrement sind gut genug Primärschlüssel.

Ich bevorzuge Guid. Ein potenzielles Problem bei der automatischen Inkrementierung besteht darin, dass der Wert (z. B. "Auftrags-ID") von der Datenbankinstanz (z. B. von der "Verkaufsdatenbank") zugewiesen wird. Dies funktioniert nicht vollständig (stattdessen benötigen Sie zusammengesetzte Schlüssel), wenn Sie müssen jemals Daten zusammenführen, die von mehr als einer Datenbankinstanz erstellt wurden (z. B. von mehreren Verkaufsbüros mit jeweils einer eigenen Datenbank).

RE GUID's

Achten Sie darauf, ob dies eine wirklich WIRKLICH WIRKLICH große Datenbank, viel Last und schneller Zugriff sein wird.

Bei meinem letzten Job, bei dem wir Datenbanken mit 100 bis 500 Millionen Datensätzen hatten, sprachen sich unsere Datenbank-Mitarbeiter entschieden gegen GUIDs und für eine entsprechend große Dezimalzahl aus. Sie waren der Meinung, dass (unter Oracle) der Größenunterschied im internen Speicher für eine Zeichenfolge Guid - gegenüber einem Dezimalwert einen sehr spürbaren Unterschied bei der Suche bewirken würde. (Größere Schlüssel = tiefere Bäume zum Durchqueren)

Die Zufälligkeit von GUIDs reduziert auch den Füllfaktor für Indexseiten erheblich - dies erhöht das Zerreißen und die Festplatten-E / A erheblich.

Spalten automatisch inkrementieren. Ich kann meinen Code nahtlos mit SQL Server oder Oracle zusammenarbeiten lassen, wobei einer die Identität verwendet und der andere Sequenzen über meine DAL verwendet, und ich könnte nicht glücklicher sein. Ich bin damit einverstanden, dass GUIDs manchmal erforderlich sind, wenn Sie Replikationen durchführen oder Daten wegsenden, um sie später nach der Verarbeitung zu empfangen.

Ich habe immer einen Ersatzschlüssel verwendet - eine automatisch inkrementierende Ganzzahl namens 'id'. Ich sehe viele Gründe dafür, auch wenn eine andere Option offensichtlich ist:

• Konsistenz
• Datenunabhängig (eindeutig, nicht durch Formatänderungen zerstört)
• Für Menschen lesbar

... und kein vernünftiger Grund, nicht:

• Mehrdeutigkeit bei Joins? - Aliasing-Tabellen sind meiner Meinung nach eine bessere Vorgehensweise
• Optimale Tische? - Das Entfernen eines Bytes pro Eintrag ist meiner Meinung nach eine vorzeitige Optimierung, IMHO
• Entscheidung pro Tisch? - Nicht mehr konsistent
• Skalierungsprobleme? - Eh? Warum?
• Hierarchische Datenstruktur? - Das ist Denormalisierung, ein ganz anderes Thema der Religion. Es genügt zu sagen, dass ich theoretisch unter bestimmten Umständen ein Fan bin, in der Praxis jedoch nie :)

vernünftige Gründe dagegen, an die ich noch nicht gedacht habe oder die mir noch nicht begegnet sind, sind immer willkommen ...

Dies ist ein Klassiker "es kommt darauf an". Es gibt keine richtige Antwort für jedes Projekt. Ich mag verschiedene Dinge für verschiedene Situationen. Es hängt davon ab, ob ich ein ORM verwende und was es unterstützt. Dies hängt von der Gesamtarchitektur ab (verteilt oder nicht usw.). Wählen Sie einfach eine aus, von der Sie glauben, dass sie funktioniert, und streiten Sie über Tabulatoren und Leerzeichen.

Ich neige dazu, Option 1 oder 3 zu verwenden, abhängig von der Größe, der Anzahl der Personen, die eine Verbindung herstellen, und davon, ob es sich um eine Situation mit mehreren Datenbankservern handelt oder nicht.

Option 2 macht für mich nicht viel Sinn. Wenn einer der drei Datensätze nicht ausreicht, um einen eindeutigen Datensatz zu identifizieren, können (ohne zusätzliche Bearbeitungen) zwei Datensätze mit denselben Werten in allen drei Spalten angezeigt werden. Wenn Sie die Eindeutigkeit einer beliebigen Kombination der drei erzwingen möchten, fügen Sie einfach einen Index für diese hinzu.

Ich habe nur ein Auto-Inkrement-Int oder eine GUID verwendet. 99% der Zeit habe ich Auto-Inkrement int verwendet. Es ist genau das, was mir beigebracht wurde, als ich zum ersten Mal etwas über Datenbanken gelernt habe und nie einen Grund gefunden habe, sie nicht zu verwenden (obwohl ich Gründe kenne, warum eine GUID besser wäre).

Ich mag Auto-Inkrement-Ints, weil es die Lesbarkeit verbessert. Zum Beispiel kann ich sagen "werfen Sie einen Blick auf Datensatz 129383" und es ist ziemlich einfach für jemanden, hineinzugehen und ihn zu finden. Mit einer GUID ist das fast unmöglich.

Nach einer grundlegenden definitorischen Antwort bleibt das , was einen guten Primärschlüssel ausmacht, weitgehend der Religion und den Argumenten des Pausenraums überlassen. Wenn Sie etwas haben, das einer einzelnen Zeile eindeutig zugeordnet ist und immer zugeordnet wird, funktioniert es als Primärschlüssel einwandfrei. Nach diesem Punkt gibt es noch andere Überlegungen:

• Ist die Primärschlüsseldefinition nicht zu komplex? Vermeidet es unnötige Komplexität, um einer "Best Practice" zu folgen?
• Gibt es einen besser möglichen Primärschlüssel, für dessen Verarbeitung weniger Aufwand erforderlich wäre (z. B. INTEGER vs. VARCHAR usw.)?
• Bin ich ABSOLUT sicher, dass sich die Eindeutigkeit und Definitivität meines Primärschlüssels nicht ändert?

Letzteres ist wahrscheinlich das, was die meisten Leute dazu bringt, Dinge wie GUIDs oder selbstinkrementierende Ganzzahlspalten zu verwenden, weil man sich nicht auf Dinge wie Adressen, Telefonnummern, Vor- / Nachnamen usw. verlässt. Die einzige Invariante bei Menschen, an die ich denken kann, sind SSNs, aber ich bin mir nicht einmal 100% sicher, ob diese für immer einzigartig bleiben.

Hoffentlich hilft dies, Klarheit zu schaffen ...

Die Art und Weise, wie ich mich Primärschlüsseln nähere (und ich denke, es ist die beste), besteht darin, einen "Standard" -Ansatz zu vermeiden. Dies bedeutet, anstatt nur auf eine automatisch inkrementierende Ganzzahl zu klopfen und sie einen Tag lang aufzurufen, schaue ich mir das Problem an und sage: "Gibt es eine Spalte oder eine Gruppe von Spalten, die immer eindeutig sind und sich nicht ändern?" Wenn die Antwort ja ist, dann gehe ich so vor.

Fast immer ganze Zahlen.

Sie haben andere gute Gründe, als kleiner / schneller zu verarbeiten. Was würden Sie lieber aufschreiben - "404040" oder "3463b5a2-a02b-4fd4-aa0f-1d3c0450026c"?

Nur geringfügig relevant, aber eine Sache, mit der ich kürzlich begonnen habe, wenn ich kleine Klassifizierungstabellen habe (im Wesentlichen solche, die ENUMs im Code darstellen würden), ist, dass ich den Primärschlüssel zu einem Zeichen (3) oder Zeichen (4) mache. Dann mache ich diese Primärschlüssel repräsentativ für den Suchwert.

Zum Beispiel habe ich ein Angebotssystem für unsere internen Vertriebsmitarbeiter. Wir haben "Kostenkategorien", denen jede Angebotsposition eine der folgenden zugeordnet ist ... Ich habe also eine Typ-Nachschlagetabelle mit dem Namen "tCostCategories", wobei der Primärschlüssel "MTL", "SVC", "TRV", "TAX", " 'ODC'. In anderen Spalten der Nachschlagetabelle werden weitere Details gespeichert, z. B. die normale englische Bedeutung der Codes "Material", "Service", "Reise", "Steuern", "Sonstige direkte Kosten" usw.

Das ist wirklich schön, weil es nicht mehr Speicherplatz als ein Int benötigt und wenn Sie sich die Quelldaten ansehen, müssen Sie die Nachschlagetabelle nicht verknüpfen, um zu wissen, was zum Teufel der Wert ist. Eine Anführungszeichenzeile könnte beispielsweise folgendermaßen aussehen:

1 Teilenummer $ 40 MTL
2 Andere Teilenummer $ 29.99 SVC
3 Teilenummer2 $ 150 TRV

Es ist viel einfacher, ein Int zu verwenden, um die Kategorien darzustellen, und dann 1, 2, 3 in allen Zeilen zu verknüpfen - Sie haben die Daten direkt vor sich und die Leistung scheint überhaupt nicht beeinträchtigt zu sein (nicht, dass ich ' habe wirklich getestet.)

Was die eigentliche Frage betrifft ... Ich mag RowGUID Uniqueidentifiers. Ich bin nicht zu 100% dabei, aber haben nicht alle Zeilen interne RowGuids? Wenn ja, dann würde die Verwendung von RowGuid tatsächlich weniger Platz beanspruchen als Ints (oder irgendetwas anderes). Ich weiß nur, dass es für mich gut genug ist, wenn M $ in GreatPlains verwendet werden kann. (Soll ich mich ducken?)

Oh, noch ein Grund, warum ich GUIDs verwende - ich verwende eine hierarchische Datenstruktur. Das heißt, ich habe eine Tabelle 'Firma' und eine Tabelle 'Anbieter', für die die Primärschlüssel übereinstimmen. Ich habe aber auch eine Tabelle 'Hersteller', die auch von der Firma 'erbt'. Die Felder, die Lieferanten und Herstellern gemeinsam sind, werden in diesen Tabellen nicht angezeigt - sie werden in der Firma angezeigt. In diesem Setup ist die Verwendung von Ints viel schmerzhafter als Guids. Zumindest können Sie keine Identitätsprimärschlüssel verwenden.

Ich mag natürliche Schlüssel, wann immer ich ihnen vertrauen kann. Ich bin bereit, einen kleinen Preis für die Performance zu zahlen, um Schlüssel zu verwenden, die für die Fachexperten sinnvoll sind.

Für Tabellen, die Entitäten beschreiben, sollte es einen einfachen natürlichen Schlüssel geben, der einzelne Instanzen genauso identifiziert wie die Themen, die Menschen tun. Wenn das Thema keine vertrauenswürdigen Kennungen für eine der Entitäten enthält, greife ich auf einen Ersatzschlüssel zurück.

Für Tabellen, die Beziehungen beschreiben, verwende ich einen zusammengesetzten Schlüssel, wobei jede Komponente auf eine Entität verweist, die an der Beziehung teilnimmt, und daher auf eine Zeile in einer Entitätstabelle. Auch hier ist der Leistungseinbruch bei Verwendung eines zusammengesetzten Schlüssels im Allgemeinen minimal.

Wie andere bereits betont haben, ist der Begriff "Primärschlüssel" etwas irreführend. Im relationalen Datenmodell wird der Begriff "Kandidatenschlüssel" verwendet. Es können mehrere Kandidatenschlüssel für eine einzelne Tabelle vorhanden sein. Logischerweise ist jeder genauso gut wie der andere. Die Auswahl eines davon als "primär" und das Erstellen aller Referenzen über diesen Schlüssel ist einfach eine Entscheidung, die der Designer treffen kann.

Guids.period.

Für den Fall, dass Sie skalieren müssen oder den Primärschlüssel auf alternative Weise zuweisen müssen, sind sie Ihr Freund. Sie können Indizes für alles andere hinzufügen.

Update, um meine Aussage zu verdeutlichen.

Ich habe an vielen verschiedenen Arten von Websites gearbeitet. Von kleinen Einzelservergeschäften bis zu großen, die mit mehreren DB- und Webservern unterstützt werden. Es gab sicherlich Apps, die mit automatisch inkrementierenden Ints als Primärschlüssel in Ordnung gewesen wären. Diese passen jedoch nicht zum Modell meiner Arbeitsweise.

Bei Verwendung einer GUID können Sie die ID überall generieren. Es kann von einem Remote-Server, Ihrer Web-App, in der Datenbank selbst oder sogar in mehreren Datenbanken in einer Multimaster-Situation generiert werden.

Andererseits kann eine automatisch inkrementierte INT nur innerhalb der Primärdatenbank sicher generiert werden. Auch dies könnte in Ordnung sein, wenn Sie eine Anwendung haben, die eng mit dem einen Backing-DB-Server verbunden ist, und das Skalieren ist nichts, mit dem Sie sich befassen.

Sicher, die Verwendung von GUIDs bedeutet, dass Sie nächtliche Neuindizierungsprozesse durchführen müssen. Wenn Sie jedoch etwas anderes als eine automatisch inkrementierte INT verwenden, sollten Sie dies trotzdem tun. Selbst mit einem INT als primärem Index haben Sie wahrscheinlich andere Indizes, die neu generiert werden müssen, um die Fragmentierung zu bewältigen. Daher ist die Verwendung von GUIDs kein weiteres Problem, da diese Aufgaben unabhängig davon ausgeführt werden müssen.

Wenn Sie sich die größeren Apps ansehen, werden Sie etwas Wichtiges bemerken: Alle verwenden Base64-codierte GUIDs als Schlüssel. Der Grund dafür ist einfach: Die Verwendung von GUIDs ermöglicht Ihnen das einfache Skalieren , während beim Versuch, INTs zu skalieren, viele Rahmen zum Durchspringen vorhanden sein können.

Unsere neueste App durchläuft eine Periode schwerer Einsätze, die ungefähr einen Monat dauert. Danach werden 90 +% der Abfragen für die Berichterstellung ausgewählt. Um die Kapazität zu erhöhen, kann ich während dieser großen Einfügezeit zusätzliche DB-Server aufrufen. und später diese einfach zu einer einzigen Datenbank für die Berichterstellung zusammenführen. Der Versuch, dies mit INTs zu tun, wäre ein absoluter Albtraum.

Ehrlich gesagt wird der DB-Server jedes Mal, wenn Sie eine Datenbank gruppieren oder eine Replikation einrichten, verlangen, dass Sie ohnehin GUIDs in der Tabelle haben. Wenn Sie also der Meinung sind, dass Ihr System möglicherweise wachsen muss, wählen Sie dasjenige aus, das gut ist.

Dies ist ein komplexes Thema, unabhängig davon, ob Sie es erkannt haben oder nicht. Könnte unter den Abschnitt dieser StackOverflow-FAQ fallen.

Welche Fragen sollte ich hier nicht stellen?

Vermeiden Sie es, Fragen zu stellen, die subjektiv oder argumentativ sind oder eine ausführliche Diskussion erfordern. Dies ist ein Ort für Fragen, die beantwortet werden können!

Dies wird seit Jahren diskutiert und wird auch weiterhin diskutiert. Die einzigen Hinweise auf einen Konsens, die ich gesehen habe, sind, dass die Antworten etwas vorhersehbar sind, je nachdem, ob Sie einen OO-Mitarbeiter (GUIDs sind der einzige Weg!), Einen Datenmodellierer (natürliche Schlüssel sind der einzige Weg!) Fragen. oder ein leistungsorientierter DBA (INTs sind der einzige Weg!).