既存のPostgresテーブルのJsonカラムと新しいテーブルの比較

Question

私は情報を表示しようとしている "カタログ"を持っています。この情報は、いくつかの異なるテーブルから引き出され、ユーザは、自分の「カタログ」上のそれぞれのテーブルからレコードを隠すようにプリファレンスを設定することができる。私はPostgresデータベース

を実行しています、私の質問は：

それはtable_aからレコードのtable_a_idとCATALOG_IDを保存する場所、新しいテーブル（table_a_to_catalog）を作成する（賢明なパフォーマンス）方が良いだろうユーザーがそのカタログのために非表示にしたいということです。そして、その接続を保持するために別のテーブル（table_b_to_catalog）を持っている...というように...

OR

カタログのレコード内のJSON値として非表示設定を保存する方がよいでしょうか？したがって、{"table_a" => [id1、id2、id3]、 "table_b" => [id1、id2、id3]のようになります。

Answer 1

本当にこのカタログの使用状況によります... If情報は読み込み専用であり、あなたは1日1回ジョブを実行してカタログを更新してから、jsonが改善されます。ただし、catelogの情報を更新して編集可能にしたい場合は、別のテーブルを持つことが最適です。

個人的な好みとして、私は、テーブル内のデータを維持すると思うあなたは、パフォーマンスのために負の影響を与える非常に大きなテーブルを持つ他の機能

Answer 2

のためのデータを使用したい、より柔軟に行うことができます。 postgresテーブルの「非表示」ビュー・データを保持するということは、各カタログの隠しエントリごとにDBエントリを持つことを意味します。各クライアントアプリケーションは、そのユーザーに関連する情報のためにそのテーブルをフィルタリングする必要があります。また、多くのユーザーにとっては、かなりの時間がかかる可能性があります。

一つは単に初期ロード時間わずかを減少させる表示データ（例えば、非表示プリファレンス）のhstore、JSONやCSVを含む、ユーザ・テーブルにフィールドを追加する場合。 JSONは、「非表示」とは単にクライアントサイドに表示しないことを意味します。データがクライアントに送信されないようにする場合は、hstoreがより意味を持ちます。

他の多くの要因（キャッシング）がこれ以上のパフォーマンスに影響するため、私はほとんど言いません。アプリケーションランタイムにはRedis、データウェアハウスにはPostgresを使用することができます。