it-swarm.com.de

In der Praxis werden keine Fremdschlüsseleinschränkungen verwendet. Ist es o.k?

Keine FK-Einschränkungen zu verwenden, ist die unerklärliche Regel meines Unternehmens. FK-Einschränkungen werden nur beim Entwerfen von ERD und nicht beim Erstellen von Tabellen verwendet.

Meinem Senior zufolge sind dies in der Praxis sehr zeitaufwändige Hindernisse, wenn wir uns mit dringenden Problemen befassen. Er sagt, wenn wir INSERT/UPDATE/DELETE-Anweisungen sofort verwenden müssen, blockieren die Einschränkungen die auszuführenden Anweisungen und das Schreiben von Anweisungen, während die Einschränkungen beibehalten werden, ist ebenfalls zeitaufwändig. Ich habe sogar gehört, dass viele andere Unternehmen dies tun.

Obwohl ich die Kämpfe irgendwie verstehe, bin ich mir nicht sicher, ob dies ein guter Weg ist, da es meinem Verständnis von DB völlig entgegengesetzt ist. Diese Firma ist auch mein erster Job, daher weiß ich nicht, wie andere Firmen damit umgehen.

Wie ist Ihre Meinung dazu in der Praxis? Kann das gerechtfertigt sein? Gibt es bessere Möglichkeiten? Wie gehen andere Unternehmen in dieser Angelegenheit vor?

UPDATE: Es scheint, dass dies ein weit verbreiteter Ansatz für südkoreanische Unternehmen ist. Ich habe ein paar andere Senioren gefragt, die für andere Unternehmen gearbeitet haben, und die meisten sagen, dass sie alle so vorgehen. Und sogar einer von ihnen arbeitete für ein Finanzunternehmen! Interessant...

11
user2652379

Nichts ist umsonst. Manchmal ist es auch nicht kostenlos, etwas nicht zu haben. Sowohl Fremdschlüssel als auch nicht deklarierte Fremdschlüssel sind mit Kosten und Nutzen verbunden.

Der Zweck eines Fremdschlüssels (FK) besteht darin, sicherzustellen, dass die Spalte this hier immer nur Werte enthalten kann, die von der Spalte that dort drüben stammen1. Auf diese Weise können wir sicher sein, dass wir immer nur Aufträge für Kunden erfassen, die tatsächlich existieren, für Produkte, die wir tatsächlich produzieren und verkaufen. Viele Leute halten dies für eine gute Idee.

Der Grund, warum wir sie im DBMS deklarieren, ist, dass es sich um deren Durchsetzung kümmern kann. Es werden niemals Daten zugelassen, die gegen die Regeln verstoßen. Außerdem können Sie niemals Daten entfernen, die zur Durchsetzung der Regeln erforderlich sind. Indem wir diese Aufgabe an den Computer delegieren, können wir auf die Integrität der Daten vertrauen, unabhängig davon, aus welcher Quelle sie stammen, wann sie geschrieben wurden oder welche Anwendung sie durchlaufen haben. Dies ist natürlich mit Kosten verbunden. Das DBMS muss überprüfen, ob die Regeln für jede Zeile, für jede einzelne Abfrage ständig eingehalten werden. Dies erfordert Zeit und Mühe, was den Server belastet. Außerdem müssen die Menschen DML in einer Reihenfolge einreichen, die die Regeln einhält. Kein schlaues Erzwingen eines Auftrags mehr, um danach den Administrator einzuholen. Oh nein, ungezogener Mensch, Sie müssen zuerst den Kunden, dann das Produkt (und alle erforderlichen Zeilen) erstellen und erst dann können Sie eine Bestellung erstellen.

Ohne Fremdschlüssel sind wir viel freier mit dem, was wir tun können und der Reihenfolge, in der wir es tun können. Problematische Zeilen können entfernt werden ad hoc, damit kritische Prozesse abgeschlossen werden können. Die Daten können anschließend gepatcht werden, wenn die Panik vorbei ist. INSERTs sind im Allgemeinen etwas schneller (was sich im Laufe der Zeit summiert), da keine FKs-Überprüfungen durchgeführt werden. Beliebige Teilmengen von Daten können nach Wunsch aus der Datenbank abgerufen werden, ohne dass alle unterstützenden Daten enthalten sein müssen. Und so weiter. Dies kann absolut in Ordnung sein, wenn die beteiligten Personen das System kennen, sorgfältige Notizen machen, gute Abstimmungsroutinen haben, die Konsequenzen verstehen und die Zeit haben, nach sich selbst aufzuräumen. Die Kosten sind, dass etwas, irgendwo einmal übersehen wird und die Datenbank sich in kaum kreditwürdigen Müll verwandelt.

Einige Teams legen die Schecks eher in der Anwendung als in der Datenbank ab. Auch dies kann funktionieren. Es scheint mir jedoch, dass die gesamte Serverlast bei diesem Ansatz sehr ähnlich (oder etwas höher) sein wird, aber das Risiko, dass ein bisschen Code irgendwo eingecheckt wird, ist viel höher. Mit DRI wird die Regel einmal an den Computer übermittelt und für immer durchgesetzt. Im Anwendungscode muss er mit jedem neuen Programm neu geschrieben werden.

Für meine zwei Cent bin ich alles für Fremdschlüssel. Lassen Sie die Computer das tun, was sie können, z. B. die routinemäßige wiederholte Überprüfung, ob die Spaltenwerte übereinstimmen. Wir Menschen können uns darauf konzentrieren, uns neue und interessante Dinge auszudenken. Nachdem ich vor einigen Monaten die Verantwortung für ein System übernommen habe, füge ich den meisten Tabellen FKs hinzu. Es gibt jedoch einige, bei denen ich sie nicht hinzufügen werde. Hier sammeln wir Daten aus externen Quellen. Die Kosten für das Zurückweisen dieser Zeilen sind höher als die Kosten für das Akzeptieren und späteres Korrigieren fehlerhafter Daten. Für diese wenigen Tabellen gibt es also keine Fremdschlüssel. Ich mache das mit offenen Augen, weil ich weiß, dass wir Überwachungs- und Korrekturverfahren haben.

1Ich erkenne die Existenz mehrspaltiger Fremdschlüsseleinschränkungen an.

22
Michael Green

Ihr Senior ist ekelhaft falsch. FK-Einschränkungen sind eine Codezeile, um die Datenintegrität sicherzustellen. Was braucht mehr Zeit,

  • buchstäblich eine Codezeile in einer deklarativen Sprache und manchmal weniger, da Sie Fremdschlüssel inline hinzufügen können, wenn Sie die Tabelle CREATE.
  • oder um Integrität anzunehmen und die Nachteile fehlgeschlagener Annahmen zu behandeln.

Es gibt keinen Grund nicht, Fremdschlüsseleinschränkungen und eine relationale Datenbank zu verwenden. Sie haben zwei Jobs als SQL-DBA:

  • Erstellen Sie ein Schema mit DDL.
  • Zugriffsschema mit DML.

Wenn Sie die Integrität Ihrer Daten mit dem Schema nicht sicherstellen, überspringen Sie einfach einen Teil des Jobs. Die Natur einer Transaktion besteht darin, alles oder nichts zu gewährleisten. Sie möchten "all" definieren, ohne Fremdschlüsseleinschränkungen zu verwenden? Das ist eine Pita.

CREATE TABLE foo ( int a PRIMARY KEY );
CREATE TABLE bar ( int b REFERENCES foo );
CREATE TABLE baz ( int b );

Führen Sie nun eine atomare Transaktion für bar und baz durch

  1. fügt in foo.a den Wert (1) ein. Schlägt fehl, wenn der Wert vorhanden ist.
  2. fügt in eine andere Tabelle (bar.b oder baz.b) den gleichen Wert 1 ein und schlägt fehl, wenn der Wert in foo.a nicht vorhanden ist.

Welches ist zeitsparend?

5
Evan Carroll

Es ist fast immer besser, Fremdschlüsseleinschränkungen zu deklarieren, als Fremdschlüssel ohne Einschränkung im DBMS zu verwenden. Die Fremdschlüsseleinschränkung behält die referenzielle Integrität bei, wodurch eine Form der Datenbeschädigung verhindert wird.

Die Alternative, die referenzielle Integrität auf Anwendungsebene durchzusetzen, kostet fast immer mindestens so viel Computerressourcen und Programmieraufwand wie die DBMS-Einschränkung.

Die Alternative, die referenzielle Integrität nicht aufrechtzuerhalten, führt normalerweise zu beschädigten Daten und unzuverlässigen Ergebnissen.

Die Chancen stehen sehr groß, dass die Richtlinien Ihrer Website von Anfang an falsch waren. Es gibt Ausnahmen, aber es gibt nur wenige.

2
Walter Mitty

Dies ist etwas, das wirklich für Ihre eigene Situation getestet werden müsste, aber um die Datenintegrität von Fremdschlüsseln zu gewährleisten und gleichzeitig Daten zu löschen oder zu aktualisieren, die Sie möglicherweise in Kaskadierung untersuchen.

CREATE TABLE ChildTable (
    id INT NOT NULL IDENTITY(1,1), 
    parent_id INT,
    FOREIGN KEY (parent_id)
        REFERENCES parent(id)
        ON DELETE CASCADE
);
2
MrTCS