Gibt es eine kanonische Quelle, die „All-Surrogate“ unterstützt?

8

Hintergrund

Der Ansatz "All-PK-muss-Ersatz sein" ist in Codds relationalem Modell oder einem SQL-Standard (ANSI, ISO oder anderen) nicht vorhanden.

Auch kanonische Bücher scheinen sich diesen Einschränkungen zu entziehen.

Das Oracle-eigene Datenwörterbuchschema verwendet in einigen Tabellen natürliche Schlüssel und in anderen Tabellen Ersatzschlüssel. Ich erwähne dies, weil diese Leute ein oder zwei Dinge über RDBMS-Design wissen müssen.

PPDM (Professional Petroleum Data Management Association) empfiehlt dieselben kanonischen Bücher wie:

Verwenden Sie Ersatzschlüssel als Primärschlüssel, wenn:

  1. Es gibt keine natürlichen oder geschäftlichen Schlüssel
  2. Natürliche oder geschäftliche Schlüssel sind schlecht (häufig ändern)
  3. Der Wert des natürlichen oder Geschäftsschlüssels ist zum Zeitpunkt des Einfügens des Datensatzes nicht bekannt
  4. Mehrspaltige natürliche Schlüssel (normalerweise mehrere FK) überschreiten drei Spalten, was Verknüpfungen zu ausführlich macht.

Ich habe auch keine kanonische Quelle gefunden, die besagt, dass natürliche Schlüssel unveränderlich sein müssen. Ich finde nur, dass sie sehr stabil sein müssen, dh nur in sehr seltenen Fällen geändert werden müssen, wenn überhaupt.

Ich erwähne PPDM, weil diese Leute auch ein oder zwei Dinge über RDBMS-Design wissen müssen.

Die Ursprünge des "All-Surrogate" -Ansatzes scheinen auf Empfehlungen einiger ORM-Frameworks zu beruhen.

Es ist richtig, dass der Ansatz eine schnelle Datenbankmodellierung ermöglicht, indem nicht viel Geschäftsanalyse durchgeführt werden muss, sondern auf Kosten der Wartbarkeit und Lesbarkeit des SQL-Codes. Es wird viel Vorkehrung für etwas getroffen, das in Zukunft passieren kann oder nicht (die natürliche PK hat sich geändert, sodass wir die RDBMS-Kaskaden-Update-Funktionalität verwenden müssen), auf Kosten der täglichen Aufgabe, z. B. mehr Tabellen in jeder Tabelle verbinden zu müssen Abfragen und Schreiben von Code zum Importieren von Daten zwischen Datenbanken, ein ansonsten sehr einfaches Verfahren (aufgrund der Notwendigkeit, PK-Kolisionen zu vermeiden und zuvor Stufen- / Äquivalenztabellen erstellen zu müssen).

Ein anderes Argument ist, dass auf Ganzzahlen basierende Indizes schneller sind, dies muss jedoch mit Benchmarks unterstützt werden. Offensichtlich sind lange, unterschiedliche Varchare nicht gut für PK. Indizes, die auf kurzen Varchars mit fester Länge basieren, sind jedoch fast so schnell wie Ganzzahlen.

Die Fragen

- Gibt es eine kanonische Quelle, die den Ansatz "All-PK-must-be-Surrogates" unterstützt?

- Wurde das relationale Modell von Codd durch ein neueres relationales Modell ersetzt?

Tulains Córdova
quelle
"autoritativ" kann ein besserer Begriff sein als "kanonisch". Der letztere Begriff impliziert, dass wir ein bestimmtes Projekt oder eine bestimmte benannte Philosophie diskutieren und nicht eine allgemeine Regel für das Datenbankdesign.
DougM
6
Nun, ich kenne keine kanonische Quelle, aber meiner Erfahrung nach funktionieren die "All-PK-Must-Be-Surrogate", genauer gesagt die "PK sollte immer ein automatisch generiertes Feld mit dem Namen TablenameID", sehr, sehr gut. Ich habe gesehen, dass ich in der Praxis mit einer Datenbank in Unternehmensgröße mit mehr als 500 Tabellen arbeite, und seitdem verwende ich diese, wann immer möglich, für die Datenbankmodellierung.
Doc Brown
2
Antworten: 1) Nein! 2) Noch größer NEIN !
Nvogel
5
Müssen dieser Frage eine große -1 geben. Dass Ersatzschlüssel von der Datenbank nicht benötigt werden, ist ein Indikator dafür, dass sie kein "Muss" sind. Wie andere bereits betont haben, ist die konsequente Verwendung eine kluge Idee und hilft, Komplikationen zu vermeiden, wenn sich Daten ändern.
Großmeister
Das Wort "Ersatz" wird in diesem Zusammenhang in mehr als einem Sinne verwendet. In der frühen Verwendung wurde ein natürlicher Schlüssel als Ersatz für eine Entität beschrieben. Entitäten wie Personen oder Verkehrsflugzeuge werden nicht wirklich in die Datenbank aufgenommen. Sie sind keine Daten. Der natürliche Schlüssel identifiziert eine Entität und besteht aus Daten. So kann es die Entität innerhalb der Datenbank darstellen. Vorausgesetzt natürlich, dass das Unternehmen den natürlichen Schlüssel nicht schlecht verwaltet. Bei der späteren Verwendung wird das Wort "Ersatz" in dem Sinne verwendet, dass ein künstlicher Schlüssel als Ersatz für den natürlichen Schlüssel verwendet wird.
Walter Mitty

Antworten:

9

"Alle PKs sind Ersatz" ist überhaupt keine sehr solide Strategie und sicherlich keine, für die Sie wahrscheinlich jemals eine "maßgebliche" Quelle finden werden .

Denken Sie zunächst darüber nach, was in diesem Zusammenhang unter "Primärschlüssel" zu verstehen ist. Im relationalen Modell gibt es keine "Primärschlüssel" - dh keinen Schlüssel, der sich grundlegend von anderen Schlüsseln derselben Tabelle unterscheidet. Grundsätzlich können und haben alle Schlüssel in einer relationalen Datenbank denselben Status und dieselben Merkmale und Funktionen, sofern der Datenbankdesigner nichts anderes wählt. Das Herausgreifen eines Schlüssels in einer Tabelle mit mehreren Schlüsseln ist daher im Wesentlichen willkürlich (das war das von EFCodd verwendete Wort), subjektiv und rein psychologisch (die Ansicht von Chris Date, Codds Kollege und Mitarbeiter). Sofern nicht erklärt wird, welche Unterscheidung zwischen einem "Primärschlüssel" und einem anderen Schlüssel getroffen wird, ist es daher ziemlich bedeutungslos und überhaupt nicht wert, zu behaupten, dass ein solcher Schlüssel "

Zweitens hat das Argument sehr wenig mit Indizes zu tun, die eine physische Speicherfunktion darstellen. Schlüssel sind eine logische Angelegenheit, keine physische, und es gibt keinen absoluten Grund anzunehmen, dass die Speicherüberlegungen eines "Primärschlüssels" sich von denen anderer Schlüssel unterscheiden oder unterscheiden sollten (siehe vorherigen Absatz). Wir können davon ausgehen, dass unabhängig von den verwendeten Speicherstrukturen der Speicheraufwand bei einem Ersatzschlüssel in gewissem Maße größer ist als bei keinem solchen Schlüssel, aber wie immer lautet die beste Antwort hier "es kommt darauf an". Lagerungsentscheidungen sollten von Fall zu Fall getroffen werden, und pauschale Regeln helfen kaum.

Drittens macht aus logischer Sicht die absolute Anforderung eines Ersatzschlüssels wenig Sinn. Die Anforderung an einen natürlichen Schlüssel ist mit oder ohne Ersatz genau gleich. Die Notwendigkeit, dass Informationen im Bereich des Diskurses identifizierbar sind (dh mit einem natürlichen Schlüssel AKA "Business Key", "Domain Key"), ist derselbe. Ja, Schlüssel müssen möglicherweise aktualisiert werden, aber manchmal liegt das in der Natur der Sache. Das Hinzufügen eines Ersatzes an sich erleichtert die Handhabung von Schlüsselaktualisierungen nicht unbedingt und kann sie manchmal erschweren.

nvogel
quelle
ausgezeichnete Antwort. Zu diesem Punkt gibt es noch viel mehr zu sagen, aber eine längere Antwort hätte es nicht besser gemacht. Sie haben die wesentlichen Punkte gut zusammengefasst.
Walter Mitty
13

Primär- und Fremdschlüssel müssen nicht lesbar sein. Ihr Zweck ist es, die interne relationale Struktur der Datenbank beizubehalten und nicht von einem Menschen gelesen zu werden.

Wenn es einen geeigneten natürlichen Schlüssel gibt, der sich nie ändern wird (ich behaupte, diese sind so selten wie Hühnerzähne oder vierblättriges Kleeblatt, aber ...), können Sie das natürlich verwenden, und einige Kunden werden dies zu einer ihrer Anforderungen machen .

Aber warum sollte die zusätzliche Komplexität eines Datenbanksystems hinzugefügt werden, um nur einen geringen nennenswerten Nutzen zu erzielen? Primäre Ersatzschlüssel werden vom System generiert, sind garantiert eindeutig, ändern sich garantiert nie und haben für alle Tabellen den gleichen Datentyp. Sie haben unter allen Umständen das gleiche zuverlässige Verhalten.

Wenn Sie nach einer kanonischen Ressource suchen, die diese Praxis unterstützt, werden Sie keine finden. Es gibt genauso viele Designer auf der anderen Seite des Ganges, die ihre Verwendung natürlicher, zusammengesetzter Schlüssel mit gruppierten Indizes als Primärschlüssel bösartig verteidigen, und alle kanonischen Ressourcen sagen, dass es die Wahl des Designers ist.

Siehe auch
http://en.wikipedia.org/wiki/Surrogate_key

Robert Harvey
quelle
2
@ Bobson: Ich habe bereits in meiner Antwort festgestellt, dass es abweichende Meinungen gibt, und ich stimme Ihrer Position im Absatz unter der von Ihnen zitierten Aussage zu, sodass Ihre Ablehnung ... launisch erscheint.
Robert Harvey
2
"Primär- und Fremdschlüssel sollten nicht lesbar sein." !! Wer genau "vermutet" so etwas außer Robert? Die Frage bezieht sich auf das Beziehungsmodell, das so etwas sicherlich nie angenommen hat.
Nvogel
3
@sqlvogel [ seufz ] Mach sie lesbar, wenn du möchtest. Wirklich, es ist in Ordnung. Solange Sie Unveränderlichkeit und Einzigartigkeit garantieren können, können Sie sie für alles, was mich interessiert, grün streichen. Mein Punkt ist, dass die Lesbarkeit auf der Wichtigkeitsskala sehr gering ist.
Robert Harvey
2
@ RobertHarvey Natürlich. Sie haben auch keine Einwände dagegen, Ihre Meinung zu hören, aber Ihr erster Satz liest sich ein wenig zu sehr, als würden Sie eine implizite Eigenschaft oder Absicht dieser Dinge behaupten. Wie bereits andere sagten, ist "Unveränderlichkeit" keine Voraussetzung. Stabilität (ein relativer Begriff, kein absoluter) ist ein nützliches oder wünschenswertes Attribut des Schlüssels; Unveränderlichkeit ist nicht und ist sowieso illusorisch.
Nvogel
3
@RobertHarvey, Wenn Sie nicht mit Situationen vertraut sind, in denen die Nichtverwendung eines Ersatzes eine bessere Option ist, können einige Leute zu dem Schluss kommen, dass Sie nicht am besten beraten können, wann oder wann Sie sie nicht verwenden sollten. Ich habe nicht die Absicht, etwas zu kommentieren, das über Witless-pedia geschrieben wurde.
Nvogel