Warum sollte ein Schlüssel explizit angegeben werden?

15

Ich bin sehr neu im Thema Datenbanken, daher klingt dies vielleicht unwissend, aber ich bin neugierig, warum ein Schlüssel in einer Tabelle explizit angegeben werden sollte. Soll dies in erster Linie dem Benutzer mitteilen, dass der angegebene Spaltenwert (hoffentlich) in jeder Zeile eindeutig ist? Die Einzigartigkeit sollte auch dann noch vorhanden sein, wenn sie nicht erwähnt wird.

primary-key unique-constraint

— dsaxton
quelle

Meinen Sie damit, dass Sie, wenn Sie einen EINZIGARTIGEN Schlüssel haben, sich die Mühe machen sollten, einen PRIMÄREN zu haben?

— Vérace,

1

Warum werden sie überhaupt deklariert? Es scheint sehr hilfreich, aber ist es tatsächlich notwendig, eine Datenbank zu haben, die funktioniert?

— Dsaxton

1

Sie werden nicht benötigt, damit Ihre Datenbank funktioniert, aber sie werden benötigt, damit Ihre Daten "funktionieren", dh konsistent sind, denn genau so weisen Sie Ihren Datenbankserver an , die Informationen konsistent zu halten .

— Andriy M

Wenn die Datenbank weiß, dass ein bestimmtes Feld ein Schlüssel ist, können Sie damit die Zeile mit dem Schlüssel viel schneller finden, als wenn Sie alle Zeilen in den Tabellen durchsuchen müssen. Indizes sind ein sehr wichtiger Bestandteil der Nützlichkeit von Datenbanken.

— Thorbjørn Ravn Andersen

32

Sie schlagen offensichtlich vor, dass CONSTRAINTs in einer Datenbank von der / den Anwendung (en) erzwungen werden sollen, die / die auf diese Datenbank zugreifen?

Es gibt viele Gründe, warum dies eine schlechte Idee ist.

1) Wenn Sie eine "Roll-Your-Own" -Einschränkungs-Engine (dh innerhalb Ihres Anwendungscodes) erstellen, emulieren Sie lediglich das, was Oracle / SQL Server / MySQL / PostgreSQL / <. Whoever ...> ausgegeben hat Jahre schreiben. Ihr CONSTRAINT-Code wurde in diesen Jahren von buchstäblich Millionen von Endbenutzern getestet .

2) Bei allem Respekt vor Ihnen und Ihrem Team werden Sie es auch in wenigen Jahren nicht richtig machen - von hier aus hat MySQL-Code allein 40 Millionen Dollar gekostet. Und MySQL ist der billigste der drei oben genannten Server und implementiert nicht einmal CHECK CONSTRAINTs. Offensichtlich ist es schwierig, RI (Referential Integrity) vollständig richtig zu machen.

Ich war oft in den Oracle-Foren und kann Ihnen nicht sagen, wie oft ein armer Manager / Programmierer ein Projekt angestoßen hat, bei dem das Genie, das zuvor seinen Job hatte, die "gute" Idee hatte, das zu tun, was Sie vorschlagen .

Jonathan Lewis (er schrieb ein 550-seitiges Buch über die Grundlagen des Oracle-Optimierers ) gibt als Nr. 2 seiner Design Disasters finden sich in einem anderen Buch (" Tales of the Oak Table " - der Oak Table ist eine Gruppe von Oracle-Experten)

Wir werden die Datenintegrität auf Anwendungsebene überprüfen, anstatt die Möglichkeiten von Oracle zur Einschränkungsprüfung zu nutzen.

3) Auch wenn Sie RI wie durch ein Wunder richtig implementieren können, müssen Sie es für jede Anwendung, die diese Datenbank berührt, immer wieder vollständig neu implementieren - und wenn Ihre Daten wichtig sind, werden es neue Anwendungen sein. Wenn Sie dies als Paradigma wählen, werden Sie und Ihre Programmierkollegen (ganz zu schweigen von Support-Mitarbeitern und Verkäufen) ein Leben in ständiger Brandbekämpfung und Elend erleben.

Lesen Sie hier , hier und hier, warum die Implementierung von data CONSTRAINTs auf Anwendungsebene geradezu Wahnsinn ist .

Um Ihre Frage konkret zu beantworten:

Warum werden sie überhaupt deklariert? Es scheint sehr hilfreich, aber ist es tatsächlich notwendig, eine Datenbank zu haben, die funktioniert

Der Grund , dass KEYs (entweder PRIMARY, FOREIGN, UNIQUEoder nur gewöhnlich INDEXn) deklariert sind , ist , dass, während es nicht unbedingt notwendig für eine Datenbank , sie zu haben für sie funktionieren, ist es unbedingt erforderlich , dass sie dafür Funktion deklariert werden , gut .

— Vérace
quelle

1

Danke für deine Antwort. Ich werde wahrscheinlich mehr lernen müssen, um es vollständig zu verstehen. (Ich gehöre eigentlich nicht zu einem Team, ich lerne nur aus Neugier über Datenbanken.)

— Dsaxton

2

Lesen Sie ein paar Bücher (Date, Garcia-Molina ...) und wenden Sie sich an uns, wenn Sie spezielle Fragen haben (Fragen, die zu weit gefasst sind, werden hier als nicht thematisch behandelt). ps Willkommen im Forum :-)

— Vérace

Ich würde niemals vorschlagen, dass Sie der Datenbank keine Einschränkungen auferlegen (Sie sollten immer mindestens einen Primärschlüssel und Fremdschlüssel haben), aber Sie könnten # 3 vermeiden, indem Sie alle Apps von einem gemeinsamen Dienst konsumieren lassen (serviceorientierte Architektur) ). (Dies sollten Sie wahrscheinlich auf jeden Fall für mehrere Verbraucher in Betracht ziehen, da das Durchführen der letzten Integritätsprüfung, die Sie in der Datenbank benötigen, auch zu Albträumen führen kann. Denken Sie daran, dass überall ständig Überprüfungen über Tabellen und Zeilen hinweg durchgeführt werden.)

— jpmc26

10

Wenn Sie einen Schlüssel in einer Datenbank erstellen, erzwingt die DBMS-Engine eine Eindeutigkeitsbeschränkung für die Schlüsselattribute. Dies dient mindestens drei verwandten Zwecken:

Datenintegrität: Doppelte Daten können nicht in Schlüsselattribute eingegeben werden. Abhängigkeiten von den Schlüsseln sind somit gewährleistet.
Identifikation: Benutzer können sich auf Schlüssel verlassen, um Daten genau zu identifizieren und zu aktualisieren.
Optimierung: Die Informationen (Metadaten) darüber, welche Attribute eindeutig sind, stehen dem DBMS-Abfrageoptimierer zur Verfügung. Mit diesen Informationen kann das Optimierungsprogramm die Ausführung von Abfragen auf bestimmte Weise vereinfachen, sodass Abfragen schneller ausgeführt werden.

— nvogel
quelle

8

Ich werde einen Aspekt zu den vorhandenen hervorragenden Antworten hinzufügen: Dokumentation. Oft ist es wichtig zu sehen, welche Arten von Schlüsseln Sie zum Identifizieren einer Entität verwenden können. Jede Kombination eindeutiger Spalten ist ein Kandidatenschlüssel.

Der Primärschlüssel ist in der Praxis in der Regel ein besonders nützliches Konzept.

Unabhängig davon, ob Sie einen Schlüssel erzwingen oder nicht (Sie sollten dies wahrscheinlich tun), ist die Dokumentation für sich allein von Nutzen.

— boot4life
quelle

1

Datenbankdiagramme! Das erste, was ich immer tue, wenn ich gefragt werde, ob etwas Sinnvolles über Software gesagt werden soll, mit der ich nicht vertraut bin, ist zu prüfen, ob eine relationale Datenbank verwendet wird, und wenn ja, zu versuchen, ein Datenbankdiagramm zu erstellen. Das gibt mir einen guten Überblick über die Informationen, mit denen die Anwendung arbeitet. Leider deklarieren 90% der Datenbanken, die ich gesehen habe, keine Fremdschlüssel, daher sind die Diagramme nur Tabellensätze. Das Herleiten impliziter Fremdschlüssel auf Anwendungsebene erfordert Rätselraten und Optimierungen.

— Reinierpost

1

@reinierpost da stimme ich voll zu. Die Daten sind das wertvollste zu dokumentierende und zu bereinigende Objekt, da sie für immer bestehen bleiben. Code kann sich ändern; es ist tendenziell vorübergehender.

— boot4life

@reinierpost - Konsultiert für ein Unternehmen , das die mitgelieferten Software für die gesamte Bahninfrastruktur eines großen europäischen Landes (groß - man denkt Milliarden von Widgets) und ich sagte : „Hum, ich werde läuft nur eine Abfrage , um die zu prüfen , FOREIGN KEYDefinitionen a zu erhalten für das System fühlen ". Meine Anfrage ergab zip !!! Sicher, dass mein SQL falsch gewesen sein muss, erwähnte ich dies einem der leitenden Programmierer. Mit Stolz (nicht weniger) kündigte er an (als würde er einen neugeborenen Sohn präsentieren), dass das System keine FKs habe, weil "alle Suchen auf PRIMARY KEYs" seien - (irrelevant). <Doh ...> a la Homer Simpson!

— Vérace

5

Ein weiterer Grund, warum Sie CONSTRAINTs anstelle von Inside-Application-Code verwenden sollten:

Was passiert, wenn ein Entwickler / DBA eine Anweisung zum Einfügen / Aktualisieren / Löschen verwendet, um die Daten direkt in der Datenbank zu ändern? In diesem Fall ist Ihre gesamte anwendungsbasierte referenzielle Integrität unbrauchbar. Ich weiß, manche Entwickler mögen die Möglichkeit, Daten direkt zu ändern, ohne sich um RI kümmern zu müssen, weil sie wissen, was sie tun - zumindest die meiste Zeit (aber nicht immer)

PS: Natürlich können Sie Trigger erstellen, aber diese sind normalerweise sehr langsam (im Vergleich zu CONSTRAINTS).

— Thomas Franz
quelle