連絡先管理者/名簿のようなアプリケーションを設計していますが、データベースの設計を決定できません。
現在の設定では、住所、電話番号、電子メール、および組織を含む連絡先があります。現在、すべての連絡先プロパティは、連絡先テーブルへのfkを持つ個別のテーブルです。言うまでもなく、連絡先はこれらのプロパティをいくつでも持つことができます。
連絡先をアプリに読み込みたい場合は、これらすべてのテーブルを結合します。関連するテーブルではフィルター、逆引き参照、並べ替えなどが実行されないため、連絡先テーブルの直接プロパティに関連するフィールドをjsonエンコードリストとして保存する方が適切で簡単なソリューションではありませんか？
たとえば、3つのエントリを持つ電話番号テーブルへのfkを使用した連絡先の代わりに、すべての電話番号をエンコードして、連絡先テーブルのフィールドに保存しますか？
どんな洞察も本当にありがたいです！（fyi私はDjangoを使用していますが、それは実際には問題ではありません）
アプリがこれらの他の機能を必要とするように成長しないことを保証できますか？後でこれらすべてを簡単にサポートできないように、本当に自分自身を隅に塗りつぶしたいですか？
一般に、非正規化はパフォーマンス上の理由でのみ発生します。そして、正規化されたデータのコピーはライブ作業用に保持され、非正規化されたデータは、静的スナップショットが適切であるオフライン処理に使用されます。
結合の記述に慣れます。これがSQLの仕組みです。そうしなければならないということは、何かが間違っているという意味ではありません。
現在5つのSQLテーブルとしてモデル化されているデータを取得し、それを一般的な複数値型に変換することを提案しているようです（SQL製品はこれを適切にサポートしていますか？）これが「非正規化」を構成することを確認できる唯一の方法は、1NFに違反することを提案していました。その時点で、データはリレーショナルではなくなるため、データストアとしてSQLを放棄することもできます。そうしないと、データは引き続き正規化されますが、SQLを使用して属性をクエリする機能が失われます（SQL製品に複数値属性をクエリするための拡張機能がない場合）。決定的な要因は次のようです。SQLを使用してこれらの属性をクエリする必要がありますか？
手遅れだとは思いますが、同じ問題を抱えている人にとっては。
IMO、この場合はメタデータモデリングが最適です。 http://searchdatamanagement.techtarget.com/feature/Data-model-patterns-A-metadata-map