データの重複を避ける必要がありますか？
私は比較的単純なERPシステムを設計しようとしています。しかし、物事を少し複雑にするいくつかの要件があります：
- クライアントや同僚を含め、あらゆる種類の連絡先をpeopleテーブルに追加できる必要があります。
- ユーザーが自分のスケジュールなどにアクセスできるように、ユーザーを連絡先に割り当てることができる必要があります。
- たとえば、ユーザーが複数の組織で働いている場合、ユーザーを複数の顧客に割り当てることが可能でなければなりません。
- 組織ごとに、1人のユーザーの連絡先の詳細が異なる可能性があります。
- 将来的には、プロジェクト管理機能が追加されたときに、組織間でプロジェクトを共有できるようにする必要があります。
私はこの単純なデータモデルを思い付きました：
ご覧のとおり、テーブル間でデータが重複しています。
顧客の組織名を削除して、代わりに顧客の連絡先フィールドから取得する必要がありますか？はい、お客様の連絡先は、当社から請求書などを受け取る人です。これは良い設計上の決定ですか、それともpeopleテーブルを使用しない方がいいですか？
ユーザーの名前は連絡先の名前の重複ですが、これは避けられないと思いますか？ユーザーの詳細を連絡先の詳細に関連付けたくありません。ポイント4を参照してください。
繰り返しますが、これは物事を視覚化するための非常に単純な「モックアップ」ですが、このモデルにどのような改善を加えることができますか？もっとエレガントな方法はありますか？
TL; DR;正規化は適切なアプローチであり、問題が発生する場合は、アプローチに問題があることを示している可能性があります。問題を再設計してください。
私はこれを可能な限り（そして合理的に）正規化します。なぜなら、それが一般により良い設計につながるからです。たとえば、「people」テーブルは「contact_info」テーブルのように見えますが、それが当てはまる場合は、おそらく名前は必要ありません。
次に：組織にはおそらく名前が必要ですが、人（別名顧客？）にも名前があります。これは何か違うからです。
最後に、ユーザーはおそらく名前を必要としませんが、ログイン（またはログインとして使用できる場合は電子メール-覚えやすく、すでに使用されているユーザー名を処理する必要がないため、これは良い習慣だと思います） ）とパスワードが必要です。
このような設計では、顧客は1つまたは複数の組織に属することができ（後者の場合、その接続には追加のテーブルが必要です）、組織はdafault_contactこれはcontact_info.idまたはcustomers.idへのFKです（この場合、何がより意味があるかを決定するのはあなたです）。
このようなアプローチでは、組織、顧客、実際の人を受け入れる「人」テーブルはありません（これは紛らわしいです）-実際に含まれているものでテーブルに名前を付けます：contact_data、person（個人データ）、company（tax id、websiteurlなど）。 ）、ユーザー、および必要に応じて顧客（以下を参照）。
顧客テーブルを指定するための質問-顧客は会社のみでも個人でもかまいませんか？ -顧客は誰にも割り当てられていない会社になることができますか？
回答は、個人/組織テーブルに「is_customer」が必要かどうかを判断するのに役立ちますOR FK person_idまたはorganization_idまたはその両方を含むCustomersテーブル.