私が集めたものから、 を使用する主な利点は 2 つあり、 をREFERENCES
使用する場合と使用しない場合で重要な違いがありますFOREIGN KEY
。
DBMS に最適化の余地を与える
REFERENCES を使用しないと、SQLite は属性id
と属性wizard_id
が機能的に同等であることを認識できません。データベース管理システム (この場合は SQLite) に対して定義できる既知の制約が多いほど、内部でデータを処理する方法を最適化する自由度が高くなります。
優れた実践を強制または奨励することができます
参照宣言は、強制や警告規定にも役立ちます。たとえば、 と の 2 つのテーブルがA
あり、それが と機能的に同等B
であると仮定して、結合を試みるとします。これら 2 つの属性間の機能上の同等性を示すために REFERENCE が使用されていない場合、DBMS は、結合を行うときに警告を表示できます。同じこと。A.name
B.name
SELECT * FROM A, B WHERE A.name = B.name
REFERENCES
常に「外部キー」を作成するとは限りません
すでに提案されていることとは反対に、参照と外部キーは同じものではありません。参照は、属性間の機能的同等性を宣言します。外部キーは、別のテーブルの主キーを参照します。
編集: @IanMcLaird は私を修正しました: を使用すると、REFERENCES
常に何らかの外部キーが作成されますが、これは、「別のテーブルの主キーを参照するテーブル内の属性のセット」としての一般的な外部キーの定義と競合します。 (ウィキペディア)。
REFERENCES
withoutを使用FOREIGN KEY
すると、「外部キー」の一般的な定義に反して動作する「列レベルの外部キー」が作成される場合があります。
次のステートメントには違いがあります。
driver_id INT REFERENCES Drivers
driver_id INT REFERENCES Drivers(id)
driver_id INT,
FOREIGN KEY(driver_id) REFERENCES Drivers(id)
Drivers
最初のステートメントは、属性が指定されていないため、主キーを参照することを前提としています。3 番目のステートメントでは、id
が の主キーである必要がありDrivers
ます。どちらも、上記の一般的な定義によって外部キーを作成することを前提としています。どちらもテーブル レベルの外部キーを作成します。
2 番目のステートメントはトリッキーです。の主キーである属性を指定する場合Drivers
、DBMS はテーブル レベルの外部キーの作成を選択する場合があります。ただし、指定された属性はの主キーである必要はありませんDrivers
。そうでない場合、DBMS は列レベルの外部キーを作成します。これは、データベースに初めて取り組み、「外部キー」の一般的な定義の柔軟性に欠けることを学ぶ人にとっては、やや直感的ではありません。
一部の人々は、これら 3 つのステートメントを同じものであるかのように使用する場合があり、多くの一般的なユース ケースでは機能的に同一である可能性がありますが、同じではありません。
とはいえ、これは私の理解です。私はこのテーマの専門家ではありません。追加、訂正、確認をいただければ幸いです。