2017-11-22 5 views
1

は、テーブルを作成するための移行です:Rails 5.1 - primary_keyとforeign_keyにデータベースインデックスを作成する必要がありますか?ここ

class CreateTemplates < ActiveRecord::Migration[5.1] 
    def change 
    create_table :templates, id: :uuid do |t| 
     t.references :account, type: :uuid, foreign_key: true 
     t.string :name 
     t.text :info 
     t.string :title 

     t.timestamps 
    end 
    end 
end 

ACCOUNT_IDがFOREIGN_KEYである(と顧客を識別する)ので、それは、このテーブルの上でクエリのほぼ全て(99%)が表示されます - 多くのポイントがありません別の顧客に属しているテンプレートを検索することができます。

account_id foreign_keyに対して作成された上記のインデックスを削除して、代わりにこのインデックスを作成する必要がありますか?

add_index :templates, [:id, :account_id], unique: false 

オリジナルを保持し、これを追加する必要がありますか? 99%のユースケースを明確にするために

EDIT

- 私は私が間違っていたと思います。テンプレートを作成する際、account_idは常に挿入されるため、tempaltes_controllerのindexメソッドは常にaccount_idを使用してすべてのテンプレートを返すので、ユーザーは自分のアカウントに属するテンプレートのリストしか見ることができません。編集、更新、削除の場合、それらのアクションはtemplate_idのみが必要です。だから私の99%の推測は間違っています!ほとんどのクエリは実際には私のような複合キーを必要としません。

答えて

2

ほとんどのクエリが[:id、:account_id]の組み合わせでフィルタリングされる場合、コンポジットインデックスを作成するとクエリのパフォーマンスが向上します。

しかしほとんどのクエリでは:account_idが必要なように聞こえますが、その場合は複合インデックスを追加する必要はありません。

+0

この回答をお寄せいただきありがとうございました。 EDITセクションを追加しました。私はほとんどのクエリは、テンプレートテーブルのidフィールドを使用すると思います - インデックスアクションはaccount_id(そのアカウントのテンプレートのみを返す)が必要です。したがって、ほとんどのクエリでは、account_idではなく、独自のテンプレートIDが必要になると思われます。その理由で、複合キーは必要ないと思いますよね? – rmcsharry

+0

よろしくお願いします。foreign_keyのインデックスは、リストしたすべてのユースケースをカバーする必要があります。 Idフィールドはテンプレートの主キーです。すでにインデックスがあります。 – xeon131

関連する問題