データモデリングに関する私のアドバイスは次のとおりです。
- 1：1結合よりもオプションの（null許容）列を優先する必要があります一般的に言えば 。 1：1が理にかなっている場合もあり、通常はサブタイピングを中心に展開します。 null許容列に関しては、奇妙なことに結合よりもきしむ傾向があります。
- モデルを作成しないでください 本当にでない限り、間接的 正当化されます（これについては以下で詳しく説明します）;
- 集約よりも優先結合。これは変動する可能性があるため、テストする必要があります。 Oracle vs MySQL vs SQL Server：集約を参照してください。対参加 この例については;
- 結合は、N+1が選択するよりも優れています。 N + 1選択とは、たとえば、データベーステーブルから注文を選択し、別のクエリを発行して、その注文のすべての広告申込情報を取得することです。
- 結合のスケーラビリティは通常です。 一括選択を行う場合にのみ問題が発生します。単一の行を選択し、それをいくつかのものに結合する場合、これが問題になることはめったにありません（ただし、問題になる場合もあります）。
- 外部キーは常に必要です 些細な小さなテーブルを扱っている場合を除いて、インデックスに登録されます。
詳細については、AppDevelopersによるデータベース開発の間違い をご覧ください。 。
モデルの直接性について、例を挙げましょう。ユーザーの認証と承認のためのシステムを設計しているとしましょう。過剰に設計されたソリューションは、次のようになります。
- エイリアス（id、username、user_id）;
- ユーザー（id、...）;
- メール（id、user_id、メールアドレス）;
- ログイン（id、user_id、...）
- ログインロール（id、login_id、role_id）;
- 役割（id、name）;
- 役割特権（id、role_id、privilege_id）;
- 特権（ID、名前）。
したがって、入力されたユーザー名から実際の特権を取得するには、6つの結合が必要です。確かにこれには実際の要件があるかもしれませんが、すべてのユーザーがエイリアスを1つしか持っていなくても、いつか必要になるかもしれないと考えている開発者による手作業のために、この種のシステムが導入されることがよくあります。ログインするユーザーは1です。 ：1など。より簡単な解決策は次のとおりです。
- ユーザー（ID、ユーザー名、メールアドレス、ユーザータイプ）
そして、まあ、それだけです。おそらく、複雑な役割システムが必要な場合でも、必要がない可能性も十分にあります。必要な場合は、スロットインするのがかなり簡単です（ユーザータイプがユーザータイプまたは役割テーブルへの外部キーになります）。古いものから新しいものへ。
これは複雑さに関することです。追加は簡単で、削除は困難です。通常、それは意図しない複雑さに対する絶え間ない警戒です。これは、不必要な複雑さを追加することによって悪化することなく、十分に悪いことです。