2017-01-18 3 views
-2

Kein Problem, sondern eine Frage zu Best Practice und was für mich in Zukunft funktionieren wird.Fremdschlüssel im Datenbankdesign

Ich habe eine Reihe von Tabellen, die Daten enthalten, die auf Konten in meinem Schema verknüpft sind - Dienstleistungen, Standorte, Anbieter etc.

ich zwei Möglichkeiten habe, kann ich einen Fremdschlüssel zu Konten, um alle hinzufügen meine Tabellen, die die Anzahl der benötigten Joins reduzieren, aber potentiell zu den gespeicherten Daten beitragen und (möglicherweise?) zu Inkonsistenzen führen.

Also meine Frage ist, sollte ich ein Konto FK Dienstleistungen, Standorte usw. hinzufügen oder auf Joins verlassen, um das für mich zu verwalten?

+2

Fremdschlüssel und die Anzahl der Joins haben nichts miteinander zu tun. Außerdem sind Fremdschlüssel vorhanden, um die Datenintegrität sicherzustellen. Ich verstehe nicht wirklich, wie das Hinzufügen von mehr zu Inkonsistenzen in Daten führen würde. Deine Frage ist mir wirklich nicht klar. – Shadow

+0

Warum möchten Sie redundante Daten übertragen, die möglicherweise zu Inkonsistenzen führen können? Die Anzahl der Joins ist wirklich keine wichtige Metrik. Wenn Sie sich Gedanken über die Leistung machen, benchmarken Sie das normalisierte Design und sehen Sie, was Sie mit der Indizierung erreichen können. – reaanb

+0

Bitte geben Sie 'SHOW CREATE TABLE' für jede relevante Tabelle an. –

Antwort

1

Ohne die Struktur Ihrer Datenbanken zu kennen, ist es schwierig, eine korrekte Antwort zu geben. Aber nehmen wir zum Beispiel eine einzelne Tabelle providers. Wenn ein Anbieter nur einen Account haben kann, würde ich der Tabelle providers einen FK hinzufügen. Wenn dies nicht der Fall ist, würde ich keinen FK verwenden, weil es nicht funktionieren würde.

Fremdschlüssel sind Dinge miteinander zu verknüpfen, so dass es keine Inkonsistenz gibt. Also, wenn Sie eine employees Tabelle und eine departments Tabelle hätten, hätte employees eine FK zu departments, weil ein Angestellter nur in einer Abteilung sein kann.

0

Sie scheinen einige Probleme zu haben, FK zu verstehen und was sie Ihnen geben.

Ihr FK sollte sich einer Tabelle mit einem PK (Primärschlüssel) anschließen, um die Datenintegrität zwischen den Tabellen zu gewährleisten.

Wenn Sie jedoch die Spalten des FK nicht indexieren, handelt es sich um einen nicht indizierten FK, was zu vollständigen Tabellen-Scans in Ihren Joins führen kann.

PKs und FKs sind nur Einschränkungen und fügen nicht zum Speicher hinzu. Das Indizieren eines FK fügt dem Speicher hinzu, aber die Leistungsvorteile von Indizes überwiegen normalerweise den Speichermehraufwand.

Die Verwendung von PKs und indexierten FKs sind Teil des normalisierten Datenentwurfs und Sie sollten keine Bedenken haben, sie zu verwenden.