「フレキシブル」テーブルと固定テーブルのヘルプ
SQL Serverでデータベースを設計して、販売手数料を処理しています。現在のスキーマの図は次のようになります。
プロジェクトに参加しているのは数人だけで、上司がこのデザインを私たちに落としました。私は初心者ですが、Slotテーブルについて心配していました。EAVモデルに向かっているようで、私たちのチームは落とし穴を乗り切るのに十分な経験がないと思います。
Slotは、会社、場所、地域、ルート、または位置（SlotTypeに基づく）にすることができます。これらのエンティティのテーブルがありますが、経営陣はスロットを相互に割り当てる "柔軟性"（SlotHierarchy）を望んでいます。すべてのスロット、スロットタイプ、スロットレベル、スロットレベルタイプ、および従業員の職階割り当てに適用される有効日の混乱については説明しません。すべての発効日は、経営陣がすべての部分を管理したいためです。
計画では、Employeeを位置スロット（SlotPositionAssignment）に割り当て、それをロケーション、ルート、またはリージョンスロットに割り当てることができます。ポジションには、一度に1人の従業員しか割り当てることができません。ただし、ポジションは任意の数のスロットに割り当てることができます。
したがって、PositionType "Salesman"とSlotDescの2つのポジション（スロット）に "Sales 1"と "Sales 2"があり、それぞれに従業員が割り当てられています。これらの2つの位置は、複数のルート、地域、場所、または会社のスロットに割り当てることができます。 SlotHierarchyはこれを整理するのに役立ちます。
私の懸念：
私はこれで足で自分自身を撃つかもしれないと思います。追加のアプリケーションロジックを作成してもかまいませんが、これは「賢すぎる」ようです。 「スロット」として隠すのではなく、スペードをスペードと呼び、実際にマップするテーブルを使用することは、意味がありませんか？
スロットとしての位置をなくしてPositionテーブルを使用するか、PositionTypeだけを使用したかったのですが、特定の「Rt 1マネージャー」のような会社のポジション。私がこれを持ち出したとき、それは「柔軟」ではないと言われ、それで終わりでした。
これを整理したり、妥協したりするためのより良い方法はありますか、それとも私は何も心配していませんか？私は初心者なので、間違っていることを気にしないでくださいなぜ私は間違っています。
このシステムの使用例について考えてみることをお勧めします。クエリが特定のデザインと代替案をどのように検索するかを自分の頭の中で考え出します。スロット間を移動するシナリオを含めます。アップデートはどのように見えますか？ DRIでビジネス上の制約を強制できますか？目的の値をまだ見つけることができますか？実際に話し合う例があると、懸念が浮き彫りになり、上司がモデルをより完全に説明できるようになります。
恐ろしいスキーマに対するホラークエリの記述は、問題の一部にすぎません。誰かが壊れた場合、文書を使わずに午前3時にそれらを修正する必要があります。この段階でよりわかりやすいクエリを実行すると、より良いシステムがより早く得られます。
それがあなたの神経を落ち着かせるなら、私はEAVシステムで成功しました。とはいえ、私たちは非常に経験豊富なDBAのチームであり、それは実際には青空の「what if」プロジェクトでした。本番環境に移行する開発プロジェクトでは、EAVアプローチを使用しないことを強くお勧めします。
「柔軟な」ルートを使用する場合は、一般的なスキーマがあるという理由だけで一般的なクエリを記述しないでください。各クエリは、会社、場所、地域のいずれか、またはスロットタイプが何であっても処理する必要があります。
私の2セント相当。