Sollte jede Tabelle einen Einzelfeld-Ersatz- / künstlichen Primärschlüssel haben?


33

Ich verstehe einen Vorteil von Ersatz- / künstlichen Schlüsseln im Allgemeinen - sie ändern sich nicht und das kann sehr praktisch sein. Dies gilt unabhängig davon, ob es sich um Einzel- oder Mehrfachfelder handelt - sofern es sich um künstliche Felder handelt.

Es scheint jedoch manchmal eine Angelegenheit der Politik zu sein, ein automatisch inkrementierendes Ganzzahlfeld als Primärschlüssel jeder Tabelle zu haben. Ist dies immer die beste Idee, einen solchen Einzelfeldschlüssel zu haben, und warum (oder warum nicht)?

Klar ist, dass es bei dieser Frage nicht um künstliche oder natürliche Schlüssel geht, sondern darum, ob alle künstlichen Schlüssel ein Einzelfeld sein sollten


Antworten:


28

Ich werde nein sagen , nicht immer, aber die meiste Zeit ja. .

Unter folgenden Umständen benötigen Sie keinen Ersatz- oder künstlichen Schlüssel:

  • Reine Kreuzungstabellen . Wenn kein Risiko besteht, dass die Schnittmenge das Ziel eines Fremdschlüssels ist, und wenn kein oder nur ein geringes Risiko besteht, dass die Schnittmenge unabhängige Attribute (dh etwas anderes als FKs für die beiden übergeordneten Tabellen) anzieht, können Sie die Kombination verwenden von FKs als PK mit fairem Vertrauen.
  • Nachschlagetabellen mit statischen Geschäftsschlüsseln . Wenn Sie über eine Nachschlagetabelle
    mit einem eindeutigen Geschäftsschlüssel verfügen, der extern für Ihr
    Unternehmen festgelegt wurde und der keine Chance hat, sich für einen
    praktischen Zweck zu ändern , kann die direkte Verwendung des Geschäftsschlüssels die
    Dinge vereinfachen. Ein Beispiel könnte eine Liste von Bundesstaat- oder
    Provinzcodes oder eine Liste von ANSI-Standardnummern usw. sein.
  • Tabellen mit Daten, die aus mehreren unabhängigen Quellen konsolidiert wurden . Wenn Ihr System über viele Datenquellen verfügt, die in einer einzigen Tabelle zusammengefasst werden müssen, z. B. in der Zentrale, benötigen Sie manchmal einen zusammengesetzten Schlüssel, der den Schlüsselwert des Quellsystems und einen Code enthält, der angibt, um welches Quellsystem es sich handelt.

Es gibt auch Situationen, in denen der altgetreue, monoton ansteigende ganzzahlige Ersatzschlüssel nicht ideal ist. Sie können alphanumerische Ersatzschlüssel verwenden. Dazu könnten gehören:

  • Situationen, in denen Sie Daten aus mehreren unabhängigen Quellen zusammenführen müssen. Um Schlüsselkollisionen zu vermeiden, können Sie GUIDs anstelle von IDENTITY-Schlüsseln verwenden.
  • Situationen, in denen Sie gezwungen sind, nicht numerische Tastendarstellungen zu verwenden. Nehmen wir an, Sie haben eine Kfz-Kennzeichendatenbank. Ihr Schlüssel könnte der alphanumerische Wert anstelle einer reinen Zahl sein.
  • Situationen, in denen Sie aufgrund einer externen Anforderung gezwungen sind, den Schlüsselwert zu komprimieren. Anstatt 10 Ziffern für ein int32 zu verwenden, können Sie sechs Base-36-Ziffern verwenden.

Warum die meiste Zeit ja? Die grundlegendste Antwort auf diese Frage ist, dass es die reinste Hölle ist, wenn Sie jemals einen Primärschlüsselwert in einer Tabelle ändern müssen. Da fast alles, was ein Benutzer sehen oder berühren kann, möglicherweise irgendwann aktualisiert wird, lädt die Verwendung eines sichtbaren Schlüsselwerts zur Hölle ein. Wenn Sie einen Ersatzschlüssel verwenden, können Sie nicht in diese Falle tappen.

Denken Sie jedoch daran, dass YAGNI bei der Anwendung dieses Konzepts Spielraum hat. Sie müssen keine Codetabellen mit IDENTITY-Schlüsseln in jede Ecke Ihres Schemas zwingen, nur für den Fall, dass jemand entscheidet, dass das Symbol für das männliche Geschlecht in Ihrer Mitarbeitertabelle von M auf X oder etwas Dummes geändert werden muss.


"Die Verwendung eines Ersatzschlüssels verhindert, dass Sie in diese Falle tappen." Es geht nicht um Ersatz gegen natürliche, sondern um Einzel- gegen Mehrfach-Ersatz.
Jack Douglas

Wie Sie in einem Kommentar zu Ihrer eigenen Antwort bestätigt haben, sind wir uns darüber einig, dass wir nicht einverstanden sind, wenn es um das umsichtige Entwerfen von Datenbanken geht. In Anbetracht Ihrer Bearbeitung hätte ich nicht zwischen Ersatz- und Naturschlüsseln unterschieden, sodass mein zweiter Aufzählungspunkt verspätet vom Thema abweicht. Meine anderen Punkte, wann man vom klassischen Identitäts- / Sequenzansatz abweichen könnte, bleiben bestehen.
Joel Brown

Ich habe die Frage nicht geändert, wie Sie aus der Geschichte ersehen können, sondern nur hervorgehoben, wo ich dachte, es würde den Lesern
Jack Douglas

12

Nein.

Ich würde sagen, dass es sicherlich Fälle gibt, in denen Einzelfeldschlüssel zusammengesetzten Schlüsseln unterlegen sind, zumindest für den Zweck von Fremdschlüsseln . Das heißt nicht, dass Sie auch keinen Ersatzschlüssel mit einem einzigen Feld haben sollten, aber ich persönlich bevorzuge den Schlüssel, der am häufigsten als Ziel eines Fremdschlüssels verwendet wird, der als Primärschlüssel bezeichnet wird

Ich werde versuchen, meinen Standpunkt in den folgenden Beispielen zu veranschaulichen, in denen:

  • brand ist eine Automarke, zB Ford, Toyota usw
  • dealer ist ein physischer Händler, der an eine Marke gebunden ist (z. B. ein Ford-Händler, der nur Fords verkauft)
  • model ist der Autotyp zB Ford Focus, Ford Fiesta etc
  • stock ist die aktuelle Anzahl der Vorplatzfahrzeuge für jedes Autohaus

Wenn wir einen Einzelfeld-Ersatzschlüssel für dealerund modelwie folgt erstellen :

create table brand( brand_id integer primary key );

create table dealer( dealer_id integer primary key, 
                     brand_id integer references brand )

create table model( model_id integer primary key, 
                    brand_id integer references brand )

create table stock( model_id integer references model, 
                    dealer_id integer references dealer, 
                    quantity integer,
                      primary key(model_id, dealer_id) )

dann ist es möglich, eine Reihe einzufügen stock, die einen Ford dealermit einem "Toyota" -Modell verbindet. Das Hinzufügen brand_id references brandzu stockmacht das Problem nur noch schlimmer. Auf der anderen Seite, wenn wir den Fremdschlüssel als Teil des Primärschlüssels behalten, wie folgt:

create table brand( brand_id integer primary key );

create table dealer( brand_id integer references brand, 
                     dealer_id integer, 
                       primary key(brand_id, dealer_id) )

create table model( brand_id integer references brand, 
                    model_id integer, 
                      primary key(brand_id, model_id) )

create table stock( brand_id integer, 
                    model_id integer, 
                    dealer_id integer, 
                    quantity integer,
                      primary key(brand_id, model_id, dealer_id),
                      foreign key(brand_id, model_id) references model,
                      foreign key(brand_id, dealer_id) references dealer )

Jetzt wird die Regel, dass "Ford" -Händler nur "Ford" -Autos auf Lager haben dürfen, vom Modell auf natürliche Weise durchgesetzt.

Beachten Sie, dass in dem Beispiel für 'zusammengesetzte Schlüssel' dealer_idje nach Vorliebe möglicherweise eindeutig ist oder nicht. Es muss nicht eindeutig sein (dh ein alternativer Schlüssel), aber es geht sehr wenig verloren, wenn man es so anlegt (vielleicht ein wenig Speicherplatz), und es kann sehr praktisch sein, so wie ich es normalerweise einrichte, zB:

create table dealer( brand_id integer references brand, 
                     dealer_id serial unique, 
                       primary key(brand_id, dealer_id) )

3
Unter Berücksichtigung der üblichen Maßgaben, dass Beispiele nicht unbedingt in jeder Hinsicht perfekt sind, würde ich sagen, dass diese Art der Gestaltung besonders spröde ist. Die Suche nach einer Möglichkeit, DRI zur Durchsetzung von Geschäftsregeln zu verwenden, ist zwar befriedigend, beeinträchtigt jedoch auch Ihre Fähigkeit, auf Änderungen zu reagieren. Wenn Toyota einen Ford kauft oder sich ein Ford-Händler für den Verkauf eines gebrauchten Toyota entscheidet, werden Ihnen Ihre DRI-gesteuerten Geschäftsregeln Kopfschmerzen bereiten.
Joel Brown

1
"Ihre Geschäftsregeln könnten sich also ändern". Dies gilt für jede Geschäftsregel und wird möglicherweise immer schwierig zu modellieren sein. Normalerweise wird mir gesagt, welche Geschäftsregeln gelten - ich entscheide sie nicht für mich.
Jack Douglas

1
Wollen Sie damit sagen, dass DRI überhaupt nicht zur Durchsetzung von Geschäftsregeln verwendet werden sollte? Ist das nicht das Einzige, was DRI macht? - Selbst einfache Fremdschlüssel sind Geschäftsregeln, die von DRI durchgesetzt werden.
Jack Douglas

4
Natürlich setzt DRI Geschäftsregeln durch. Sie müssen entscheiden, welche Regeln im Code und welche in Ihrem Schema durchgesetzt werden. Schemaänderungen sind fast immer schwieriger als Codeänderungen. Es gibt zwei Arten von Geschäftsregeln, die in Ihr Datenmodell aufgenommen werden können. Man gehört dorthin und man nicht. Die grundlegende Natur der Daten, die für Ihr Unternehmen wichtig sind, ändert sich nicht sehr. Die Art und Weise, wie Sie mit diesen Daten arbeiten, ist sehr viel unbeständiger . Eine Regel, wie Autos einen Hersteller haben, gehört in das Datenmodell. Eine Regel wie Händler wird niemals zwei Marken von Autos verkaufen, nicht.
Joel Brown

4
"Schemaänderungen sind fast immer schwieriger als Codeänderungen" IMO ist das Gegenteil der Fall. Eigentlich bin ich mit so gut wie allem, was Sie gerade gesagt haben, nicht einverstanden, aber ich bezweifle, dass es irgendeinen Grund gibt, mit Ihnen darüber zu streiten, also lasse ich es dabei.
Jack Douglas

12

"es hängt davon ab, ob"

Ja: Ersatzfelder für IDENTITY / AUTONUMBER sind gut, wenn der natürliche Schlüssel breit und nicht numerisch ist. Hinweis: Dies setzt die Vereinigung von "PK" und gruppiertem Index voraus, die standardmäßig in SQL Server und Sybase usw. Auftritt

Nein: viele / viele Tabellen, wenn die 2 übergeordneten Schlüssel ausreichen. Oder wenn der natürliche Schlüssel kurz und von fester Länge ist, z. B. ein Währungscode

Natürlich kann ein Kopf-ORM (gelesen: (n) Ruhezustand) diese Regeln übertreffen ...

Edit: Frage nochmal lesen

Eine Many / Many-Tabelle mit 2 übergeordneten Ersatzschlüsseln hat eine mehrspaltige PK.
Es wird jedoch keine weitere Ersatzspalte benötigt.

Wenn eine Tabelle einen Ersatzschlüssel (IDENTITY usw.) enthält, muss dieser nicht mehrspaltig sein.

Sie können einen Superschlüssel haben, der das Surrogat enthält, dies wäre jedoch, um andere Regeln (z. B. Untertypen ) durchzusetzen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.