私はアプリケーションに取り組んでいます。その主な目的は、自分の好みに基づいて他のユーザーを推奨することです（それぞれの推奨は個別に扱われます）。 良い習慣とは何でしょうか？ 3つの分離したテーブル（users、user_preferencesおよびuser_details）に情報を格納するか、2つのjsonbカラムを持つ単一のテーブルusersを使用するには？リレーショナルデータベース設計の優良事例：正規化？
1]トランザクションをOLTP（オンライントランザクション処理）とみなして、3つの別個のテーブルを計画する必要があります。さまざまな結合を使用してテーブルのデータを取得する際のパフォーマンスが向上します。スキーマを常に正規化します。
最初に、あなたがしようとしていることによっては、jsonbが最初の正規形を壊すことがあります。さんは1NFを議論しようと、それは良いアイデアである理由：
第1正規形があれば存在し、場合にのみ：
原子であり、最初の二つは、容易に理解されるが、第三のは、実際には議論があります。すべてが最大限に分解されなければならないのでしょうか？さて、datetime列が許されている限り、それは意味することはできません....
私の見解では、アトミック性の必要性について考える最も良い方法は、表内のすべての値がドメイン内の単一の値を表すことです。したがって、ここで2つのことが原子性要件1NFを破る。最初はセット（ブログ記事のタグなど、順序は関係ありません）を使用し、2番目はセット内の関数依存関係のデータを格納します。
なぜこれらの両方が関係しますか？列のセットをママージングすると、データベース内で多くの余分な作業を行う機会がたくさん生まれます。また、推移的な依存関係も問題をもたらします。たとえば、jsonb内のフィールドから別のテーブルにあるものを参照する外部キーを持つことはできません。
パフォーマンス面では、設定やアプリケーションのBLOBを保存しているだけであれば、それほど大きな違いはないので、追加機能が重要です。 PostgreSQL（他のDBについては話すことができません）は大きなフィールドをTOASTすることに注意してください。 TOASTされたフィールドは、場合によってはオーバーヘッドを課すこともあれば、他のものを追加することもありません。クエリの影響を結合よりも測定することははるかに困難です。それはそれに対するもう一つの印です。 TOASTは素晴らしいテクニックですが、無料のランチではありません。したがって、同じパフォーマンスの影響を受ける可能性がありますが、はるかに透過的です。
良い方法は、使用しているデータベースのタイプによって異なります。リレーショナルデータベースを使用している場合は、データベースを標準化します（https://en.wikipedia.org/wiki/Database_normalization）。 NoSQLデータベースを使用している場合は、文書を作成します。 –