Warum werden für Joins keine Primärschlüssel- / Fremdschlüssel-Übereinstimmungen verwendet?

48

Soweit ich herausfinden konnte, verwenden viele DBMS (z. B. mysql, postgres, mssql) fk- und pk-Kombinationen nur, um Änderungen an Daten einzuschränken, aber sie werden selten nativ verwendet, um automatisch zu verbindende Spalten auszuwählen (wie natürliche Verknüpfungen mit Namen). Warum ist das so? Wenn Sie bereits eine Beziehung zwischen zwei Tabellen mit einem pk / fk definiert haben, kann die Datenbank dann nicht herausfinden, ob ich diese Tabellen in den pk / fk-Spalten verknüpfen möchte, wenn ich sie verknüpfe.

EDIT: um dies etwas zu klären:

Angenommen, ich habe einen Tisch1 und einen Tisch2. In Tabelle 1 befindet sich ein Fremdschlüssel in Spalte a, der auf den Primärschlüssel in Tabelle 2, Spalte b, verweist. Wenn ich mich nun diesen Tabellen anschließe, muss ich Folgendes tun:

SELECT * FROM table1
JOIN table2 ON table1.a = table2.b

Ich habe jedoch bereits mit meinen Schlüsseln definiert, dass table1.a auf table2.b verweist. Daher sollte es für mich nicht zu schwierig sein, ein DBMS-System so zu konfigurieren, dass es automatisch table1.a und table2.b als Verknüpfungsspalten verwendet. so dass man einfach benutzen kann:

SELECT * FROM table1
AUTO JOIN table2

Viele DBMS scheinen jedoch so etwas nicht zu implementieren.

Tiddo
quelle

Antworten:

32

In vielen Fällen gibt es mehrere Möglichkeiten, zwei Tabellen zu verknüpfen. In den anderen Antworten finden Sie viele Beispiele. Natürlich könnte man sagen, dass es in solchen Fällen ein Fehler wäre, den "automatischen Join" zu verwenden. Dann würde nur eine Handvoll einfacher Fälle übrig bleiben, in denen es verwendet werden kann.

Es gibt jedoch einen schwerwiegenden Nachteil! Abfragen, die heute korrekt sind, können morgen schon durch Hinzufügen einer zweiten FK zur selben Tabelle zu einem Fehler werden!

Lassen Sie mich das noch einmal sagen: Durch Hinzufügen von Spalten können Abfragen, die diese Spalten nicht verwenden, von "korrekt" zu "fehlerhaft" werden!

Das ist ein solcher Wartungs-Albtraum, dass jeder vernünftige Styleguide die Verwendung dieser Funktion verbieten würde. Die meisten verbieten schon select *aus dem gleichen Grund!

All dies wäre akzeptabel, wenn die Leistung verbessert würde. Dies ist jedoch nicht der Fall.

Zusammenfassend lässt sich sagen, dass diese Funktion nur in wenigen einfachen Fällen verwendet werden kann, die Leistung nicht erhöht und die meisten Styleguides ihre Verwendung sowieso untersagen würden.

Daher ist es nicht abwegig, dass sich die meisten Datenbankanbieter dafür entscheiden, ihre Zeit für wichtigere Dinge zu verwenden.


quelle
1
Wahrscheinlich würde es tatsächlich einen kleinen Leistungseinbruch geben, da es darum geht, die Verknüpfungsspalten herauszufinden, anstatt sie zu präzisieren.
HLGEM
1
@HLGEM, Das kann zwischengespeichert werden und ist auch für größere Abfragen irrelevant. Der Vorteil ist, dass wir sicher sein können, dass Schlüssel nicht aufgrund eines menschlichen Fehlers übersehen werden.
Pacerier
Das Hinzufügen und Ändern von Spalten kann ebenfalls zu Problemen führen NATURAL JOIN(weshalb ich sie normalerweise vermeide), aber ich denke nicht, dass dies bedeuten sollte, dass ein DBMS keine automatische Methode zum Verknüpfen von Tabellen basierend auf Fremdschlüsseln implementieren kann.
Jay K
2
Viele Fälle? Auf einem DB mit 1000 Tabellen habe ich nur einige wenige Fälle mit einer Beziehung von mehr als 1 zwischen zwei Tabellen. Wie auch immer, das ist kein Problem, es würde ausreichen, einen Beziehungsnamen hinzuzufügen AUTO JOIN mytable THROUGH myrelation, es wäre sehr schön.
Teejay
Das ist, was wir in unserem maßgeschneiderten .NET SQL Builder mit Intellisense tun, wieInnerJoin(SRC_TABLE.rDEST_TABLE.REL_NAME_F01)
Teejay
27

Ein Fremdschlüssel soll die Daten einschränken . dh referenzielle Integrität erzwingen. Das ist es. Nichts anderes.

  1. Sie können mehrere Fremdschlüssel für dieselbe Tabelle haben. Beachten Sie Folgendes, wenn eine Sendung einen Start- und einen Endpunkt hat.

    table: USA_States
    StateID
    StateName
    
    table: Shipment
    ShipmentID
    PickupStateID Foreign key
    DeliveryStateID Foreign key

    Möglicherweise möchten Sie basierend auf dem Abholstatus beitreten. Vielleicht möchten Sie sich am Auslieferungszustand beteiligen. Vielleicht möchten Sie zwei Joins für beide ausführen! Die SQL-Engine hat keine Möglichkeit zu wissen, was Sie wollen.

  2. Sie werden häufig skalare Cross-Join-Werte verwenden. Obwohl Skalare normalerweise das Ergebnis von Zwischenberechnungen sind, haben Sie manchmal eine Spezialtabelle mit genau 1 Datensatz. Wenn die Engine versucht hätte, einen falschen Schlüssel für den Join zu ermitteln, wäre dies nicht sinnvoll, da Cross-Joins niemals mit einer Spalte übereinstimmen.

  3. In einigen besonderen Fällen werden Sie an Spalten teilnehmen, bei denen keine eindeutig ist. Daher ist das Vorhandensein eines PK / FK auf diesen Spalten unmöglich.

  4. Sie können denken , Punkte 2 und 3 nicht relevant sind , da Ihre Fragen zu ist , wenn es IS eine einzelne PK / FK Beziehung zwischen Tabellen. Das Vorhandensein einer einzelnen PK / FK zwischen den Tabellen bedeutet jedoch nicht, dass Sie nicht zusätzlich zur PK / FK weitere Felder zum Verknüpfen haben können. Die SQL-Engine würde nicht wissen, auf welchen Feldern Sie beitreten möchten.

  5. Nehmen wir an, Sie haben eine Tabelle "USA_States" und 5 weitere Tabellen mit einem FK zu den Staaten. Die "fünf" Tabellen haben auch ein paar Fremdschlüssel zueinander. Sollte die SQL-Engine automatisch die "fünf" Tabellen mit "USA_States" verbinden? Oder soll es die "Fünf" miteinander verbinden? Beide? Sie können die Beziehungen so einrichten, dass die SQL-Engine in eine Endlosschleife eintritt und versucht, die Elemente miteinander zu verbinden. In dieser Situation ist es unmöglich, dass die SQL-Engine errät, was Sie wollen.

Zusammenfassend: PK / FK hat nichts mit Tabellenverknüpfungen zu tun. Sie sind getrennte Dinge, die nichts miteinander zu tun haben. Es ist nur ein Zufall der Natur, dass Sie sich oft an den PK / FK-Säulen beteiligen.

Möchten Sie, dass die SQL-Engine errät, ob es sich um eine vollständige, eine linke, eine rechte oder eine innere Verknüpfung handelt? Ich glaube nicht. Obwohl das wohl eine geringere Sünde wäre, als die Säulen zum Beitritt zu raten.

Lord Tydus
quelle
7
Ich halte Fremdschlüssel und Normalisierung für sehr relevant für Tabellenverknüpfungen.
3
Ihre Argumente sind gültig, wenn das normale JOIN-Schlüsselwort immer versucht, dem zu entsprechen (wie ich es in meinem Beispiel falsch gemacht habe, werde ich das korrigieren). Viele Verknüpfungen können jedoch direkt nur von den Verknüpfungen abgeleitet werden, sodass ich keinen Grund sehe, warum es keine explizite Syntax für die Verknüpfung geben kann. Viele DBMSs haben einen natürlichen Join, der im Grunde dasselbe tut, jedoch mit Spaltennamen (= schlecht). Das Gleiche könnte mit dieser Art von Join geschehen, z. B. durch Angabe einer AUTO JOIN-Operation.
5
"Es ist nur ein Zufall der Natur, dass Sie oft an den PK / FK-Säulen teilnehmen" - ich bin nicht überzeugt!
selben Tag, am
2
"Normalisierung?" Ich denke, die Überlegung hier ist, dass, wenn Sie mit einem 1NF-Relvar begonnen und dann in 6NF-Relvar zerlegt haben, die Wahrscheinlichkeit besteht, dass a) bei der Implementierung Fremdschlüssel vorhanden sind und b) häufig Abfragen durchgeführt werden.
selben Tag, am
4
Ich würde dagegen stimmen, wenn es nicht so wäre: "PK / FK hat nichts mit Tabellenverknüpfungen zu tun."
Ypercubeᵀᴹ
11

das Konzept der "Verbindbarkeit". Relationen r1und r2sind nur dann verbindbar, wenn Attribute mit demselben Namen vom selben Typ sind ... Dieses Konzept gilt nicht nur für das Verbinden als solches, sondern auch für verschiedene andere Operationen [wie zum Beispiel union].

SQL und relationale Theorie: Wie man genauen SQL-Code nach CJ-Datum schreibt

Standard-SQL verfügt bereits über eine solche Funktion, die als " NATURAL JOINmySQL" bezeichnet und in mySQL implementiert wurde.

Obwohl Ihr Vorschlag nicht ganz so wertvoll ist, scheint er vernünftig zu sein. Mit SQL Server (für den es an Unterstützung mangeltNATURAL JOIN ) verwende ich SQL Prompt in Management Studio: Beim Schreiben eines INNER JOINInteliSense-Befehls werden ONKlauseln vorgeschlagen, die sowohl auf allgemeinen Attributnamen als auch auf Fremdschlüsseln basieren, und ich finde es sehr nützlich. Ich habe jedoch keinen großen Wunsch, einen neuen (Standard-) SQL-Join-Typ dafür zu sehen.

eines Tages, wenn
quelle
1
Natürliches Verbinden und Verbinden auf gemeinsamen Spalten unterscheidet sich von & orthogonal zum Begriff des Verbindens auf FK-PK. (Siehe meine Antwort.)
philipxy
@philipxy: Einverstanden, ich wollte nicht anders implizieren. (Sie ist eine ausgezeichnete Antwort!)
onedaywhen
9

SQL stand an erster Stelle!

Fremdschlüssel und Fremdschlüsseleinschränkungen wurden später eingeführt und sind im Wesentlichen eine Optimierung für Anwendungen im Transaktionsstil.

Relationale Datenbanken wurden ursprünglich als Methode konzipiert, um komplexe Abfragen auf Datensätze so anzuwenden, dass sie mithilfe der relationalen Algebra mathematisch nachweisbar sind . IE für einen bestimmten Datensatz und eine bestimmte Abfrage gibt es immer eine einzige richtige Antwort.

Relationale Datenbanken haben seitdem einen langen Weg zurückgelegt, und ihre primäre Verwendung als Persistenzschicht für Transaktionssysteme war nicht das, was CODD et al. alles vorgesehen.

Das ANSI-Standardgremium war jedoch stets bestrebt, die "mathematisch nachweisbaren" Eigenschaften von SQL trotz aller widersprüchlichen Ziele und Herstellerpolitik beizubehalten.

Wenn Sie der Datenbank erlauben würden, die Verknüpfungseigenschaften aus "verborgenen" Fremdschlüsseldaten abzuleiten, würden Sie diese Eigenschaft verlieren (berücksichtigen Sie die Mehrdeutigkeit, wenn mehr als ein Satz von Fremdschlüsseln definiert ist).

Auch ein Programmierer, der die SQL liest, würde nicht unbedingt wissen, welche Fremdschlüssel aktuell für die beiden Tabellen definiert sind, und müsste das Datenbankschema untersuchen, um herauszufinden, was die Abfrage tut.

James Anderson
quelle
3
Danke, das hat mir Sinn gemacht! Haben natürliche Joins nicht die gleichen Probleme? Obwohl natürliche Joins noch größere Probleme haben, werden sie von vielen DBMS unterstützt. IMO wäre eine auf pk / fk basierende Verknüpfung eine natürliche, richtig ausgeführte Verknüpfung.
1
Für die meisten Datenbank-Engines besteht kein Unterschied zwischen einem natürlichen Join und einem expliziten "JOIN ... ON". Die Engine analysiert die Abfrage und führt den Join basierend auf den verschiedenen Prädikaten so gut wie möglich aus. Die Verwendung eines expliziten Joins erzwingt nicht die Verwendung eines bestimmten Indexes oder Zugriffspfads, da dieser meistens die Join-Syntax "LEFT, OUTER, INNER" unterstützt, die die expliziten Join-Prädikate kennen muss, um zu wissen, wann eine "fehlende" Zeile eingefügt werden muss .
6
SQL kam nicht an erster Stelle! Das relationale Modell (das natürlich das Konzept von Fremdschlüsseln enthielt) wurde erstmals 1969 von EFCodd skizziert. SEQUEL erblickte, wie es damals war, erst um 1974 das Licht der Welt. Die Erfinder machten dies von Anfang an deutlich SEQUEL / SQL sollte auf dem bereits vorhandenen relationalen Modell basieren - obwohl SQL keine wirklich relationale Sprache war.
nvogel
@sqlvogel - wahr! Hätte sagen sollen: "SQL wurde zuerst implementiert".
James Anderson
CJ Date in 'Eine Einführung in Datenbanksysteme' (S276) sagt, Codd habe das Konzept des Fremdschlüssels erfunden; sagt nicht wann, aber ich nehme an, es war vor der ersten SQL-Implementierung.
Uhr
7

Während Sie eine Fremdschlüsselbeziehung definiert haben, heißt das nicht, dass Sie die Tabellen in allen Abfragen verknüpfen möchten. Es ist die wahrscheinlichste Methode zum Verknüpfen der Tabellen, aber es gibt Fälle, in denen dies nicht korrekt ist.

  • Möglicherweise möchten Sie ein kartesisches Produkt der beiden Tabellen oder einen Teil davon für einen bestimmten Zweck verwenden.
  • Möglicherweise gibt es andere Felder, in denen Sie sich für einen anderen Zweck anmelden können.
  • Wenn Sie drei oder mehr Tabellen verbinden, kann eine der Tabellen mit zwei oder mehr Tabellen verknüpft sein. In diesem Fall kann normalerweise nur eine der möglichen FK-Beziehungen in der Abfrage zutreffen.
BillThor
quelle
7

Möglicherweise gehen Sie von einer falschen Annahme aus. Sie sagen "so weit Sie es herausfinden können", geben aber keine empirischen oder nachweislichen Beweise. Wenn pk oder fk der beste Index für eine Abfrage sind, wird er verwendet. Ich weiß nicht, warum Sie das sehen, aber meine Vermutung ist schlecht formulierte Abfragen.


Bearbeiten Sie jetzt, da die Frage vollständig umgeschrieben wurde: Der Fall, den Sie beschreiben, ist nur für eine sehr kleine Anzahl von Abfragen bestimmt. Was ist, wenn 12 Tische verbunden sind? Was ist, wenn es keine FKs gibt? Auch wenn es einen Standard-Join gibt, würde ich den Join immer nur aus Gründen der Lesbarkeit angeben. (Ich möchte nicht auf die Daten schauen und dann versuchen, herauszufinden, woran sich etwas anschließt.)

Einige Abfragetools führen tatsächlich eine automatische Verknüpfung durch, mit der Sie die Verknüpfung entfernen oder bearbeiten können. Ich denke, dass der Abfrage-Generator von MS Access dies tut.

Schließlich besagt der ANSII-Standard, dass der Join angegeben werden muss. Das ist Grund genug, es nicht zuzulassen.

Idioten
quelle
3
Entschuldigung, vielleicht war ich nicht klar genug. Ich spreche nicht über Indizes, ich spreche über Verknüpfungen. Angenommen, ich habe table1 und table2 mit einem fk auf table1.a, das auf table2.b verweist. Wenn ich diese Tabellen verknüpfe, muss ich explizit angeben, dass ich sie in den Spalten a und b verknüpfen möchte (z. B. 'SELECT * FROM table1 JOIN table2 ON table1.a = table2.b '), während ich dies bereits in meiner Datenbank definiert habe Schema, dass diese beiden verwandt sind. Die Frage ist, warum ich 'SELECT * FROM table1 JOIN table2' nicht ausführen kann und das DBMS automatisch die Verknüpfungsspalten basierend auf dem fk / pk auswählen kann.
3
Besonders die Lesbarkeit machte für mich Sinn! Allerdings ist das, was der Standard so sagt, kein wirklich gutes Argument, IMO. Viele Standards haben zuvor falsche Entscheidungen getroffen (z. B. HTML).
3

Es gibt viele Gründe, warum die Datenbank dies nicht sicher tun kann, einschließlich der Tatsache, dass das Hinzufügen / Entfernen von Fremdschlüsseln die Bedeutung vorab geschriebener Abfragen einschließlich Abfragen im Quellcode der Anwendung ändert. Die meisten Datenbanken verfügen auch nicht über einen guten Satz von Fremdschlüsseln, die alle möglichen Verknüpfungen abdecken, die Sie wahrscheinlich möchten. Fremdschlüssel werden häufig entfernt, um das System zu beschleunigen, und können nicht für Tabellen verwendet werden, die in der "falschen" Reihenfolge aus der Datei geladen werden.

Allerdings gibt es keinen Grund , warum ein Abfrage - Entwurfswerkzeug oder den Texteditor kann nicht automatisch vollständig ein Join mit Hilfe von Fremdschlüsseln in der gleichen Art und Weise , wie sie Ihnen geben intellisense auf Spaltennamen. Sie können die Abfrage bearbeiten, wenn das Tool einen Fehler festgestellt hat, und eine vollständig definierte Abfrage speichern. Ein solches Tool könnte auch die Konvention der Benennung von Fremdschlüsselspalten nach dem übergeordneten Tabellennamen und gleichnamigen Spalten in der übergeordneten / untergeordneten Tabelle usw. nutzen.

(Meine Frau kann den Unterschied zwischen Management Studio und SQL Server immer noch nicht verstehen und spricht über das Starten von SQL Server, wenn sie Management Studio startet!)

Ian Ringrose
quelle
3

Natural Join „automatisch“ tritt auf Gleichheit der gemeinsamen Spalten, aber Sie sollten nur das schreiben , wenn das, was Sie wollen , basierend auf dem Tisch Bedeutungen und Ihr desied Ergebnis. Es gibt kein "automatisches" Wissen darüber, wie zwei Tabellen in einer Abfrage "verknüpft" oder auf andere Weise "angezeigt" werden sollen. Für die Abfrage müssen keine Einschränkungen bekannt sein. Ihre Anwesenheit bedeutet nur, dass die Eingaben begrenzt sein können und folglich auch die Ausgabe. Sie könnten eine Art join_on_fk_to_pk-Operator definieren, der "automatisch" pro deklarierter Einschränkung beitritt. Wenn Sie jedoch möchten, dass die Bedeutung der Abfrage gleich bleibt, wenn sich nur Einschränkungen ändern, aber keine Tabellenbedeutungen, müssen Sie diese Abfrage ändern, um die neuen deklarierten Konstanten nicht zu verwenden.belässt die Bedeutung trotz Änderungen der Bedingungen bereits gleich .

Welche Einschränkungen gelten (einschließlich PKs, FKs, UNIQUE & CHECK), hat keinen Einfluss auf die Bedeutung der Tabellen. Wenn sich die Tabellenbedeutungen ändern, können sich natürlich auch die Einschränkungen ändern. Wenn sich die Einschränkungen ändern, bedeutet dies jedoch nicht, dass sich die Abfragen ändern sollten.

Man muss keine Einschränkungen kennen, um abzufragen. Wenn wir die Bedingungen kennen, können wir weitere Ausdrücke verwenden, die ohne das Halten der Bedingungen nicht dieselbe Antwort liefern würden. B. über UNIQUE erwarten, dass eine Tabelle eine Zeile enthält, damit wir sie als Skalar verwenden können. Diese Abfragen können unterbrochen werden, wenn die Einschränkung angenommen, aber nicht deklariert wurde. Das Deklarieren einer Einschränkung, von der die Abfrage nicht ausgegangen ist, kann sie jedoch nicht aufheben.

Gibt es eine Faustregel, um eine SQL-Abfrage aus einer für Menschen lesbaren Beschreibung zu erstellen?

philipxy
quelle
2

Der Grund ist, dass es die SPRACHE gibt, und dann gibt es die zugrunde liegenden Prinzipien. Die Sprache ist spärlich und es fehlen viele Funktionen, die Sie in einer Allzwecksprache erwarten würden. Dies ist einfach eine nette Funktion, die der Sprache nicht hinzugefügt wurde und wahrscheinlich auch nicht hinzugefügt wird. Es ist keine tote Sprache, es gibt also Hoffnung, aber ich wäre nicht optimistisch.

Wie bereits erwähnt, verwenden einige Implementierungen eine Erweiterung, bei der join (column) zwei Tabellen auf der Grundlage eines gemeinsamen Spaltennamens verknüpft, der etwas ähnlich ist. Aber es ist nicht weit verbreitet. Beachten Sie, dass sich diese Erweiterung von der SELECT * FROM employee NATURAL JOIN department;Syntax unterscheidet, in der nicht angegeben werden kann, welche Spalten verwendet werden sollen. Weder verlassen Sie sich auf eine Beziehung zwischen den Tabellen, die sie unzuverlässig macht (die natürliche Verknüpfungssyntax mehr als die Erweiterung).

Es gibt kein grundsätzliches Hindernis für "innere Join-Tabelle in PKFK", wobei PKFK ein Schlüsselwort ist, das "die zwischen den beiden Tabellen definierte Fremdschlüsselbeziehung" bedeutet. Es kann Probleme mit mehreren fk in derselben Tabelle geben, die jedoch einfach einen Fehler verursachen können. Die Frage ist, ob die Leute, die die Sprache entwerfen, der Meinung sind, dass a) eine gute Idee und b) besser zu bearbeiten ist als irgendein anderer Sprachwechsel ...

jmoreno
quelle
3
Dies setzt voraus, dass es eine gute Idee ist, dass sie bereits getan haben sollten. Es ist auch wahrscheinlich, dass sie bereits darüber nachgedacht haben und beschlossen haben, dies nicht zu tun. Vielleicht ist es in der Praxis eine sehr schlechte Idee: Sjoerd erwähnte ein Beispiel, in dem eine Abfrage nur durch Hinzufügen einer neuen Spalte und einer neuen FK-Beziehung unterbrochen werden könnte. Lord Tydus erklärt auch Fremdschlüssel, die eine andere Verantwortung haben als die Art und Weise, wie Ihre Tische verbunden werden sollen.
1
@JonathanHobbs: Ich meinte, meine Antwort sei im Allgemeinen neutral. Aber das Aufgeben der Neutralität. Joerds Logik ist fehlerhaft. Änderungen an Tabellen, die bereits Abfragen unterbrechen, und das Hinzufügen einer neuen Spalte zu einem Tabellenprimärschlüssel führen entweder dazu, dass Abfragen unterbrochen werden oder falsche Ergebnisse zurückgegeben werden. Dies würde Sie in gewissem Maße davon abhalten, Spaltenänderungen sicher durchzuführen, solange die Tabellenbeziehung beibehalten wird. Dies würde wahrscheinlich die Verwendung von FK-Beziehungen erhöhen, da dies für etwas anderes als RI.Most-Joins nützlich wäre befinden sich entweder auf der PK oder enthalten die Pk. Um Multi-Fk zu verarbeiten, verwenden Sie den Spaltennamen.
Jmoreno
1

Wenn davon ausgegangen wird, dass die ON-Klausel den Feldern folgt, die auf der referenziellen Integrität basieren, wie würden Sie ein kartesisches Produkt ausführen?

Bearbeiten: Verwenden von AUTO Der Vorteil ist, dass Sie weniger tippen und nicht wissen müssen, wie sie verbunden sind oder sich an einen komplizierten Join erinnern. Wenn sich die Beziehung ändert, wird sie automatisch behandelt, aber das kommt nur in frühen Entwicklungsphasen vor.

Sie müssen jetzt entscheiden, ob alle Ihre AUTO-Joins während eines Beziehungswechsels blockieren, um der Absicht Ihrer select-Anweisung zu entsprechen.

JeffO
quelle
@JeffO: Der Hauptvorteil ist, dass es die Absicht genauer ausdrückt, in einer sehr klaren deklarativen Weise. Verknüpfungen mit Spaltennamen sagen nichts aus, außer der Tatsache, dass einige Inhalte der Spalten denen in anderen ähnlich sind (aber möglicherweise nicht vom gleichen Typ sind). Eine Verknüpfung auf einem fk ref, sagt, dass es ist ein fk ref, würde keine Spaltenliste bedeuten , dass es nur 1 fk zwischen den Tischen war, oder umgekehrt , dass es 1+ (einen mehrspaltigen Schlüssel mit mehr als 1 ref überlegen , was passiert , wenn Sie mischen die Spalten c1 = fk1_c1 und c2 = fk2_c2). Auch wenn Sie durchschnittlich mehr tippen, wäre dies gut.
Jmoreno
Die Verwendung von (INNER) JOIN ohne ON ist kein Standard-SQL. Komma, CROSS JOIN & (INNER oder ein beliebiger OUTER) JOIN ON 0 = 0 gibt kartesisches Produkt zurück.
philipxy
-1

Warum kann die Datenbank nicht herausfinden, ob ich diese Tabellen in den pk / fk-Spalten verknüpfen möchte, wenn ich sie verknüpfe?

Teile des Grundes sind:

1 - Theoretisch können Sie Tabellen in beliebigen Spalten aus den beiden Tabellen verbinden. Dies ist zwar keine gängige Praxis, aber gültig. Denken Sie daran, dass SQL wie eine Programmiersprache ist und nicht versteht, welche Informationen sich in den Spalten befinden, und dass Namen für SQL diesbezüglich nicht viel bedeuten.

2 - Es gibt verschiedene Arten von Verknüpfungen (links, rechts, innen) - Inner Joins ist nur eine davon.

3 - Der SQL-Standard kann sich an dem Prinzip orientieren, dass es sich um eine Sprache auf niedrigerer Ebene handelt, die es Dialekten auf höherer Ebene ermöglicht, damit Intelligenz zu bilden. Der Vergleich ist etwas klarer, wenn Sie an eine Sprache der 4. Generation im Vergleich zu einer Sprache der 3. Generation denken. In der Tat erlaubte Ihnen ein Tool, das ich verwendet habe, IEF, so etwas zu schreiben:

ReadEach Customer 
Where Customer Places Orders and That Customer LivesIn "California" 
and OrderValue > 100.00

Zusammenfassend ist Ihr Vorschlag interessant und könnte entweder als Teil des Standards oder als gespeicherte Prozedur implementiert werden (standardmäßig wäre dies ein Inner Join).

Keine Chance
quelle
-10

Tiddo, ich glaube, Sie haben vollkommen recht, SQL zu diesem Thema ist ziemlich dumm , und ich erinnere mich, dass ich das Gleiche über Fremdschlüssel gedacht habe, als Sie vor zehn Jahren SQL gelernt haben.

Ok, angesichts dessen musste ich schließlich diese Prüfung bestehen; und um es zu bestehen, musste ich loslassen . SQL ist eher ein Zugunglück als irgendjemand zugeben dürfte, sein Standardisierungspfad ist eine völlige Katastrophe, und einige Implementierungen sind bedrohlich abgeschlossen . Trotzdem ist es im Allgemeinen recht praktisch. (Ich bin kein K / V-Luddit)

Fremdschlüssel also ... gar nicht so praktisch. Sie sind ein wichtiges Konzept im relationalen Modell , aber die gleichnamige SQL-Funktion lässt sich nicht gut vergleichen.

Sagen Sie gerade: nicht , dass die SQL - Funktion namens verwenden Foreign Keyüberhaupt , bis Sie einen großen System mit Performance - Problemen betroffen. Explizit den Motor zu sagen , das Feld ein Fremdschlüssel ist und welches nicht wird nur für die Indizierung verwendet, und es ist unsichtbar für den Benutzer db.

Ist es irreführend?
Ja.

Werden sie es jetzt, nach 30 Jahren irregeführter Menschen, noch mächtiger machen?
Keine Chance.

Völlig ignoriert Fremdschlüssel bis notwendig ... feste SQL für mich?
Ja!

Und warum zum Teufel ist das alles überhaupt passiert?
Nun, die Funktion , die wir als Fremdschlüssel bezeichnen, wurde später zu SQL hinzugefügt. SQL ist ein Standard, der sich im Laufe der Zeit von unten nach oben entwickelt hat. Die Hersteller haben lächerliche Funktionen implementiert, während die Standardkörper mit Handflächen versehen sind.

Wie bereits erwähnt, waren Fremdschlüssel nur für die Indizierung gedacht und es war kein JOIN-Konstrukt verfügbar. (Verknüpfungen wurden mit SELECTAbfragen erstellt. JOINAbfragen sind relativ neu und nur für die Alias- SELECTFunktionalität gedacht. ) Wahrscheinlich war das Aufrufen dieses Indizierungsflags FOREIGN KEYein cleverer Namens-Hack gegenüber Konzepten der relationalen Datenbank-Theorie.


quelle
13
In Bezug auf Fremdschlüssel, nehme ich an, Sie haben nur die MyISAM-Engine auf MySQL berührt? Selbst wenn man diese kleine Schimpfe nicht beachtet, ist alles in dieser Antwort falsch.
Fk werden nicht für die Indizierung verwendet. Tatsächlich besteht ein häufiges Problem darin, keinen Index für die fk-Spalte zu haben, was sich dramatisch auf die Leistung auswirken kann.
Jmoreno