'jobs'を実行するシステムがあるとします。これらのジョブは、事実上順序付けされた一連のジョブである「統合」と呼ばれるシーケンスに配線することができます。Rails 5、Postgres配列で結合テーブルを置換する
古典的な溶液は、結合テーブルであろう：integration_order統合内のそのintegration_jobの位置である
integrations: id, name
jobs: id, name, commands
integrations_jobs: id, integration_id, job_id, integration_order
。
代わりにpostgres配列を使用した場合はどうなりますか？
結合表の代わりに配列を使用すると明らかに欠点がありますか？私たちはHeroku上でRails 5とPostgresを使用しています。
Postgres配列またはJSONまたはenumフィールドを使用できますが、パフォーマンスに影響します。
Look here
はジョインを行う必要がないため、パフォーマンスが向上しませんか？ –
第1の欠点は、あなたが、統合の例を仕事を見つけるために照会することはできませんです。
jobs table
id
1
2
integrations table
id, name, job_ids
1, i1, [1,2]
2, i2, [2]
ので、あなたはID 2を持っているジョブの統合を検索したい場合は、必要にjob_idsが2の値であるかどうかを確認します。もし積分テーブルにたくさんのレコードがあるならば、それは大きな性能問題です。
ジョインテーブルを使用している場合、これは非常に簡単なクエリであり、より高速です。 ジョイン・テーブルを使用すると何が間違っているのか分かりません。
Thanh、私はあなたが配列フィールドにインデックスを付けることができると確信しています。 https://www.postgresql.org/docs/9.5/static/gin-builtin-opclasses.html ANY/ALLと@>/<@演算子の対象となるのはこのユースケースではありませんか？ –
Postgresは現在、配列の列を外部キーとして使用できません。これは、参照整合性を失うことを意味します。また、ActiveRecordはアソシエーションの配列列を使用するようには構築されていないため、フレームワークと戦うことになります。引数を反転すると、配列の列はこの場合どのような利点がありますか？ – max
ご協力ありがとうございます。我々は、統合をバージョンアップする方が簡単だと考えました。別のテーブルの結合オブジェクトを追跡し、それらの結合オブジェクトのそれぞれの順序の履歴を記録することは、配列の履歴を持つことはより複雑です。整合性を維持するためにカスタムレールのバリデーションを書くことで、フレームワークと少し戦うことになりますが、それは結合テーブルをバージョン管理するより簡単です。 –
'has_many through：'関連付けを使い、Papertrailを使って「結合モデル」をバージョンアップできます。 – max