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

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

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.

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) )

"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.