これはDBスキーマを構造化するばかげた方法ですか、それとも完全に何か不足していますか？

私はリレーショナルデータベースでかなりの作業を行ってきましたが、優れたスキーマ設計の基本概念はかなりよく理解していると思います。私は最近、DBが高給コンサルタントによって設計されたプロジェクトを引き継ぐことを任されました。私の腸の本能-「WTF ??！？」-保証されていますか、それともこの男は私の天才であるかのような天才ですか？

問題のDBは、従業員からのリクエストを入力するために使用される社内アプリです。そのほんの一部を見るだけで、ユーザーに関する情報と、行われているリクエストに関する情報が得られます。私はこれを次のように設計します：

ユーザー表：

UserID (primary Key, indexed, no dupes)
FirstName
LastName
Department

リクエスト表

RequestID (primary Key, indexed, no dupes)
<...> various data fields containing request details
UserID -- foreign key associated with User table

シンプルでしょ？

コンサルタントは次のように設計しました（サンプルデータを使用）。

UsersTable

UserID  FirstName   LastName
234     John        Doe
516     Jane        Doe
123     Foo         Bar

部門テーブル

DepartmentID   Name
1              Sales
2              HR
3              IT

UserDepartmentTable

UserDepartmentID   UserID   Department
1                  234      2
2                  516      2
3                  123      1

RequestTable

RequestID   UserID   <...>
1           516      blah
2           516      blah
3           234      blah

データベース全体はこのように構築され、すべてのデータは独自のテーブルにカプセル化され、数値IDがすべてをリンクしています。コンサルタントはOLAPについて読んでいて、「整数検索の速度」を望んでいたようです。

また、これらすべてのテーブルを相互参照するための多数のストアドプロシージャも持っています。

これは、小規模から中規模のSQL DBに有効な設計ですか？

コメント/回答をありがとう...

私にはぴったりです。これは非常に正規化されているため、他の方法では得られない多くの柔軟性が得られます。正規化されていないデータは苦痛です。

私は、WTFが保証されているとか、その男が狂気の天才的なデザインをしているとは思わない-それはかなり標準的なデータベース正規化です。

部門テーブルを使用する理由は、部門を別のテーブルに配置しない場合、「Sales」、「sales」、「Salesmen」、「Sails」、および「Selling」部門のユーザーを処理する必要があるためです。あなたがそれを防ぐために何かをしない限り。そして、余分なテーブルを持つことは、そのための最良の方法（の一部）です。

UserDepartmentテーブルがあるべきかどうかは、より難しい呼び出しです。これは、もちろん、どちらの決定もうまくいかず、夢中にならないことを意味します。一方では、すべてのテーブルのデザインとロジックがユーザーごとに1つの部署を想定していて、それが変更され、もう何年も何年も理由なく余分な結合を行うことは現実的な可能性であり、痛みでもあります。

個人的には、UserDepartmentテーブルが多すぎると思います。たとえ含まれていても、時間が経つにつれて、部門ごとに1人のユーザーしかいないと想定するクエリを作成する可能性があるため、両方の世界で最悪の結果になります。ユーザーごとに複数の部門が許可されると、とにかくコードが機能しなくなります。

編集-多対多の関係をサポートするかどうかの重要な要因は、ビジネスルールが明確かどうかです。複数の部門のユーザーがどのように機能するかわからない場合、ユーザーが複数の部門にいる場合をコードが正しく処理できない可能性があるため、テーブルを追加しても意味がありません。

念のため、ユーザーごとに多くの部門を許可したと想像してください。次に、部門に基づいて手数料を割り当てるためのビジネスルールを実装しました。その後、複数の部門が許可されました。幸いにも、これを考慮した方法でコミッションコードを書く先見性がありました。残念ながら、両方のユーザーに各部門からのコミッションを追加しました。経営陣は、各販売の人の役割に基づいてほしいと考えました。それで、テーブルを前もって持っていてどれくらい良かったのでしょうか？「万が一のために」持っていた、まったく必要のない他のテーブルについてはどうですか？

後で編集-コンサルタントがこれらすべての中間テーブルを追加したいと考えた別の理由は、このフォローアップの質問で対処されています。 「必要なすべてのテーブルに入れる」アプローチ。

要件がユーザーごとに複数の部門を持つことである場合、この設計は理にかなっています。それについての唯一の不満はあるUserDepartmentTable持つサロゲートキーUserDepartmentIDは必要ありません（ただ作るUserIdとDepartmentId複合主キー）。

ユーザーが1つの部署にのみ属している場合、設計は理にかなっています（ただし、部署の参照テーブルはまだ良いことです）。

一部の要件は、質問では明確ではありません。正しい答えは、顧客が何を望んでいるかに依存します-私があなたなら、これについて顧客に尋ねます：

0-ユーザーと従業員の違いは何ですか？

1-従業員=ユーザーを想定して、従業員が部門を変更した場合はどうなりますか？

2-従業員のグループは1つの要求を行うことができますか？

3-従業員は複数の部門に所属できますか？CEOについてはどうですか

4-要求を行うことを許可されている従業員のサブセットはありますか？

5-従業員レコードが削除された場合、リクエストはどうなりますか（もしあれば）？

6-リクエストを削除できますか？リクエストが破棄された場合の動作（RIによって従業員レコードを削除しないようにしてください）

7-従業員は「同じ」要求を複数回行うことができます（「同じ」を定義）

8-従業員が会社を辞めるときのリクエストの処理方法（リクエストをキャンセルするか、リクエストを削除しますか？）

さらに質問があるかもしれませんが、私のポイントは、ソリューションが厳密な要件とプロジェクトの範囲に依存するということです。それが決定したら、スキーマを直接導出できます。したがって、提示された両方のソリューションが正しい場合があります。

高額なコンサルタントが行った方法で結合テーブルを使用することの潜在的な利点のいくつかを明示的に説明する2点のフォームノートを追加したいと思います。

• 適切にインデックスが付けられた場合（たとえば、UserDepartmentTableが2つの外部キーにインデックスを付ける場合）、外部キーが一意ではないため、このような結合テーブルのパフォーマンスの低下はわずかです。外部キーが一意であることが保証されている場合、私が知っている小さなデータベース理論では、ルックアップUserDepartmentTable.DepartmentはUserテーブル内の他の列をルックアップするより「難しい」ことはありません。
• 結合テーブルを使用すると、ユーザーと部門間の関連付けに関するその他の情報（作成時のタイムスタンプなど）をより柔軟に設定できます。
• 結合テーブルを使用すると、関連付けをかなり簡単に「バージョン管理」できます（たとえば、ユーザーが部門を変更したときに、UserDepartmentTable.Activefalseのようなインデックスブールフラグをトリガーし、アクティブな新しい関連付けを作成します）。2つのテーブルモデル（ユーザーと部門のみ）で部門の関連付けをバージョン管理することも可能ですが、より難しく、主キーの重複を避けるために、少なくとも1つ以上の列を追加するか、データベースアクロバットを実行する必要があります。
• これにより、1対多または多対1または多対多の関連付けを簡単に割り当てることができます。

そうは言っても、高給コンサルタントがやったことをしない理由はいくつかあります。

• 上記の利点はすべて、考えられる将来のニーズを予測するものであり、現在の状況を複雑にします。YAGNIに準拠していません。後で、2つのテーブルモデルから結合テーブルモデルに移行する移行を記述するのは簡単です。ビジネスの必要性が生じたときにそれを行うことができます。その前にそれを行うことは混乱を招く可能性があります。
• 他の開発者を混乱させます。はい、あなたの身長（コンサルタントの決定を検討している）のWeb開発者への期待は、結合テーブルを理解して認識することですが、それは必要以上に複雑であり、ビジネスニーズがないことを考えると、混乱を引き起こします。

必要な情報の完全な構造がなければ、それがひどいのかどうかは言えません。しかし、少なくとも示されている作品は「WTF」デザインのものではありません。データ構造の3番目の標準形式のように見えます（まあ、理論的には4番目と5番目もあります）。

一部のトークでは、表示されている部分の「自然」キーと「人工」キーの2つの学校間でUserDepartmentTableを配置できます。私が見ることができるように、これ以上何もありません

正規化は、多くの理由のために良いDB-開発者/デザイナーのルールで、* デ *正規化は主にスピード勝利のための開発の途中で時々使用されています