2017-10-02 4 views
1

Ich entwarf einige Tabellen mit MySQL WorkBench und setzte Fremdschlüssel in einigen Spalten, um "korrekten" Entwurfsmustern zu folgen. Dann fragte mich mein Chef, warum ich FK verwende, weil sie "nur Probleme verursachen".Performance- und Modellunterschiede zwischen indexiertem FK und indizierter Spalte

Wenn Sie sehen, was MySQL WorkBench beim Erstellen eines neuen FKs tut, erstellt es die Beziehung und einen Index dafür. Wie folgt aus:

CREATE TABLE `smx_portales-des`.`A1` (
    `idA1` INT NOT NULL, 
    `name` VARCHAR(45) NULL, 
    PRIMARY KEY (`idA1`)); 

CREATE TABLE `smx_portales-des`.`A2` (
    `idA2` INT NOT NULL, 
    `price` DECIMAL(10,2) NULL, 
    `fkA1` INT NULL, 
    PRIMARY KEY (`idA2`), 
    INDEX `fk_A2_A1_idx` (`fkA1` ASC), 
     CONSTRAINT `fk_A2_A1` 
    FOREIGN KEY (`fkA1`) 
     REFERENCES `smx_portales-des`.`A1` (`idA1`) 
    ON DELETE NO ACTION 
    ON UPDATE NO ACTION); 

Mein Chef sagte mir, Tabelle erstellen A2 wie folgt:

CREATE TABLE `smx_portales-des`.`A2` (
     `idA2` INT NOT NULL, 
     `price` DECIMAL(10,2) NULL, 
     `fkA1` INT NULL, 
     PRIMARY KEY (`idA2`), 
     INDEX fk_A2_A1(fkA1)); 

So, abgesehen von der offensichtlichen Einschränkung von FK, die nur Werte erlaubt, die auf dem anderen Tisch sind, oder NULL Gibt es eine andere Performance, einen Stylisten oder irgendeinen Unterschied in diesen Modellen?

EDIT: Ich weiß, dass FKs in DB Datenintegrität helfen, und dass es einige Kaskadenoptionen gibt, die helfen, Kinder zu entfernen/zu aktualisieren. Auch, dass der Unterschied darin besteht, dass ich im zweiten Modell einen Index in einer "emulierten" FK-Spalte verwende. Meine Wunder, wo mehr über plausible Unterschiede in diesen beiden Modellen, wie Effizienz, Größe ...

+0

Ihre zweite verwässerte Tabelle ohne Fremdschlüsseln könnte weniger Speicherplatz beanspruchen, da MySQL sich keine Gedanken über Integrität, Kaskadierung usw. machen müsste. Aber ich denke nicht, dass dies ein entscheidender Faktor wäre, den Sie wählen würden. –

Antwort

4

Ihr Chef ist falsch. Und fühlen Sie sich frei, ihm oder ihr diese Antwort zu zeigen.

Ein Schlüsselelement der Funktionalität in relationalen Datenbanken ist die Aufrechterhaltung der Datenintegrität. Ein wichtiger Teil der Datenintegrität stellt sicher, dass Fremdschlüsselbeziehungen korrekt sind.

In Ihrer Datenbank garantiert dies, dass sich a2.fka1 immer auf eine gültige Spalte in a1 bezieht (oder einen NULL Wert hat). Dies ist wichtig für Personen, die die Daten verstehen, für Personen, die Abfragen schreiben (damit Zeilen nicht versehentlich in Joins verloren gehen) und möglicherweise für den Optimierer.

Der richtige Ort, um diese Funktionalität zu erhalten, ist in der Datenbank. Sie können versuchen, dies über Anwendungen zu tun, aber die Datenbank stellt sicher, dass die Daten unabhängig von Datenmodifikationsvorgängen korrekt sind.

Schließlich sind Fremdschlüssel ziemlich flexibel. Sie (und Ihr Chef) sollten über kaskadierende Beschränkungen lernen. Sie implementieren normalerweise die Funktionalität, die von einer Anwendung benötigt wird.

+0

Es ist nicht so, dass ich nichts über Kaskadierung weiß. Ich habe mich nur über irgendwelche Unterschiede gewundert, die ich zwischen diesen Modellen nicht kannte. Ich werde den letzten Absatz bearbeiten, um das zu zeigen. – Shirkam

+0

@Shirkam. . . Sie definieren Fremdschlüssel, um die Datenintegrität zu erhalten, nicht um die Funktionalität zu verbessern. In den meisten Datenbanken gibt es praktisch keinen Platzbedarf für eine solche Definition. MySQL erstellt ungewöhnlich einen Index für den Fremdschlüssel. –

0

Auch ich arbeite derzeit irgendwo wo Fremdschlüssel nicht verwendet und nicht erzwungen werden. Ich würde jedoch dringend empfehlen, sie zu verwenden. Es sieht so aus, als ob Ihr Buh Ihnen gesagt hat, dass Sie einfach einen Index auf die Fremdschlüsselspalte setzen sollen, anstatt tatsächlich eine Beziehung mit einem Schlüssel zwischen den beiden Tabellen zu erstellen.

Die zweite Abfrage würde wahrscheinlich schneller laufen, aber ohne eine Fremdschlüsselbeziehung verlieren Sie höchstwahrscheinlich Datenintegrität und erhöhen die Wahrscheinlichkeit von verwaisten Zeilen, was ich aus erster Hand gesehen habe. Durch die Verwendung von Schlüsseln ist es schneller zu implementieren und wird möglicherweise auch schneller ausgeführt, aber es wird auf lange Sicht viel mehr Probleme für die Datenbank schaffen. Mein Rat wäre, den Schlüssel zu erstellen und dann Indizes auch zu verwenden

0

Alle Entwurfsentscheidungen sind Kompromisse. Die offensichtlichsten Dinge, die es zu handeln gibt, sind die Leistung (Zeit) und die Raumeffizienz - aber Sie sollten sich auch Sorgen um Wartbarkeit und Belastbarkeit machen.

Aus Sicht der Leistung und Raumeffizienz gibt es keinen messbaren Unterschied zwischen Ihren Optionen.

@gordonLinoff hat bereits bezüglich der Datenintegrität geantwortet, was ein Schlüsselaspekt der Belastbarkeit ist - macht es Ihr Anwendungsdesign schwieriger oder einfacher, Fehlern zu widerstehen?

Aus Gründen der Wartbarkeit erstellt ein Fremdschlüssel einen expliziten Artefakt in der Codebasis. Er besagt, dass die Datenentität a mit der Dateneinheit b verknüpft ist. Das bedeutet, dass zukünftige Entwickler sich keine Gedanken über Namenskonventionen machen müssen oder ob die Daten konsistent sind - sie können einfache Annahmen über Ihre Daten treffen.

Dies kommt zu einem geringen Preis - Ihr Client-Code muss bestimmte Arten von Fehlermeldungen behandeln, und Sie müssen den Kopf um die Kaskadenlogik wickeln, die einige Leute ein wenig lästig finden. Ich persönlich denke, dass das ein kleiner Preis ist.

Verwandte Themen