テーブル間に単純な1対多の関係を持つデータベーススキーマを設計する方法を理解しています。そのセット内の特定の関係を主要な関係として指定するための規則またはベストプラクティスが何であるかを知りたいです。たとえば、1人の人が多くのクレジットカードを持っています。私はそれをモデル化する方法を知っています。それらのカードの1つをその人のプライマリとしてどのように指定しますか?私が思いついた解決策は、せいぜいエレガントではないようです。
私の実際の状況を明らかにしようと思います。(残念ながら、実際のドメインは物事を混乱させるだけです。)私は2つのテーブルを持っており、それぞれに多くの列があります。たとえば、PersonとTaskです。いくつかのプロパティしかないProjectもあります。1人の人には多くのプロジェクトがありますが、主要なプロジェクトがあります。1つのプロジェクトには多くのタスクがありますが、1つのプライマリタスクに代替のタスクがある場合もあれば、プライマリタスクがなく、代わりに一連のタスクがある場合もあります。プロジェクトの一部ではないタスクはありませんが、厳密に禁止されているわけではありません。
PERSON (PERSON_ID, NAME, ...)
TASK (TASK_ID, NAME, DESC, EST, ...)
PROJECT (NAME, DESC)
過度の複雑さや純粋な悪を導入せずに、プライマリプロジェクト、プライマリタスク、およびタスクシーケンスをすべて同時にモデル化する方法を理解することはできないようです。
これは私がこれまでに思いついた中で最高です:
PERSON (PERSON_ID, NAME, ...)
TASK (TASK_ID, NAME, DESC, EST, ...)
PROJECT (PROJECT_ID, PERSON_FK, TASK_FK, INDEX, NAME, DESC)
PERSON_PRIMARY_PROJECT (PERSON_FK, PROJECT_FK)
PROJECT_PRIMARY_TASK (PROJECT_FK, TASK_FK)
単純な概念にはテーブルが多すぎるようです。
これが私が見つけた非常によく似た状況を扱っている質問です:データベース設計:循環依存。
残念ながら、この状況をどのように処理するかについてはコンセンサスが得られていないようで、「正しい」答えはデータベースの整合性チェックメカニズムを無効にすることでした。クールではありません。