3

人々がこの宝石を使用し、多くの人がそれを愛しているため、これはおそらく初歩的な質問ですが、目的がわかりません。私はプロジェクトを見ていますが、ここではt.references :foreign_key_table_name , :foreign_key => true、 、add_foreign_key :table :foreign_key_table_name, :options、および createなどの場所で何度も使用されていますt.foreign_key :foreign_key_table_name。文脈から外れているため、混乱しないことを願っています。

しかし、これがレールに組み込まれているものとどのように異なるのか、t.references :foreign_key_table_nameまたは単に追加するだけではわかりませんt.integer :foreign_key_table_name_idか? これが「外部キー」であることを明確にすることで、読みやすくするだけですか？その場合は、宝石の代わりにコメントを追加することもできます...私が見る唯一の利点は:dependent、モデルに含めるのではなく、移行などのオプションを移動できることですが、誰が気にしますか?

4

3 に答える 3

10

一部のデータベースエンジンは、正当な外部キー制約をサポートしています。誰かが5で保存しようとしChildたが、parent_id5で保存しようとした場合、データベース自体（Railsではなく）は、とをリンクする外部キー制約がある場合、レコードを拒否します。Parentidchildren.parent_idparents.id

外部キーは、親が削除された場合に何が起こるかを指定することもできます。たとえば、MySQLでは、Railsが行う方法のように、依存レコードを削除または無効にすることができます。:dependentあるいは、削除を直接拒否してエラーをスローすることもできます。

すべてのデータベースエンジンがこの機能を提供しているわけではないため、Railsはそれをでエミュレートすることを提案します。親が削除されたときに:dependent依存する子レコードがコールバックを起動できるように、ソフトウェアレベルでそれを使用すると便利です。destroyこの機能はエンジンに依存せず、したがってスキーマにほとんど依存しないため、Railsは外部キーの作成/削除を処理しません。そこで登場するのforeignerは、エンジンが外部キー制約をサポートしていて、データの整合性にさらに自信を持たせたい場合にforeigner役立ちます。

于 2013-02-05T22:53:22.287 に答える
6

ここで古い質問を復活させますが…</p>

Rails に関係を強制させることは、Rails 自体の中で問題ありません。

ただし、プロジェクトが成長して、他の言語からもこれらのテーブルにアクセスするコードが含まれるようになった場合、Rails が関係を強制する利点はありません。これらの外部キー制約は SQL テーブル自体に組み込まれているため、レール以外のコードを保護できます。

これにより、データ修正を実行する必要がある場合や、ネイティブ SQL を介してデータを操作する必要がある場合にも保護されます。

于 2014-05-13T09:38:35.163 に答える
0

もう 1 つの理由は、SQL のドキュメント ツールの中には DB 上の外部キーを参照するものがあるため、外部キーを生成する gem があると便利です。Rails 4 では、テーブルを作成するのと同じ移行で外部キーを定義する機能が追加されました。

t.references :something, foreign_key: true

タイプを使用すると、ジェネレーターがこれを行いますreferences。このようsomething_idに使用すると、Railsはデフォルトでインデックスを追加しますforeign_key

于 2016-11-17T22:01:11.750 に答える