database-design - 単一テーブル継承の適用

Question

その質問から：

要約：

• 私のCRUDは、顧客、従業員、支店です。
• CustomersとEmployeesは、1つPerson、1つIndividual（個人自体に関連するフィールド）、および1つUser（ログイン目的）に関連付けられています。したがってIndividual、sとUsersは常に1人Customerまたは1Employee人に関連しています。
• Branchesは1Personつと1つCompany（企業人に関連するフィールド）に関連付けられています。したがって、Companysは常に1Branch人の人に関連しています。このデータベースが表す会社に所属しているため、ユーザーがいませんでした。アプリに認証できるのは従業員です。
• は1つEmployeeに属しBranchます。ABranchには0個または多数Employeeのsがあります。（ええ、図は正しくありません、ごめんなさい！）
• 現在、私は役割を区別するために1ビットを使用していますEmployee-私には運用および管理権限を持つ従業員がいます。役割のアクセス許可はコード自体に含まれます。ここで、顧客にも独自の役割があることがわかります...顧客と従業員の両方の役割を管理するためのより良い（そして簡単な）方法を実装するための提案はありますか？

MVCパターンをより適切に使用するために、適切に設計された単一テーブル継承を実現するために、その間違った3NF構造をどのように変更する必要がありますか？

私は少し単純化しようとしました、そして今私はこの新しい構造を達成しました：

それでも改善できますか？どこ？それをどのようにモデル化しますか？

Answer 1

市区町村の新しいテーブルを作成する価値があるのは、カーディナリティが通常の低い場合 (ユニーク数が少ない/繰り返しが多い場合) だけです。そのため、ユーザーによっては、自分で決定する必要があります。一方、住所テーブルと電話番号テーブルを切り離すことができます。

従業員と顧客について保存している情報の種類に応じて、その人が従業員か顧客かを示すフィールドだけを持つことも、2 つの別々のテーブルを持つこともできます。

役割について話す場合、通常、従業員の権限/地位/アクセシビリティを示します。つまり、レギュラー、P/T、マネージャーです。各グループ/役割のコンテンツのアクセス レベルと可視性を開発できます。

Person からすべての個人情報を取り出し、新しいテーブルに保存します。(ちょっと興味があります.. 本当にnicknameフィールドが必要ですか? ディスク I/O は、あらゆるアプリケーションの最大のボトルネックの 1 つです) 個人の詳細を専門的な詳細や ID から分離します。

Branch について話していますが、連絡先は常に 1 つだけですか? 通常、ビジネスの世界ではそうではありません。ただし、支店/人は常に1つの住所しか持たないため、ここでは個別の住所テーブルが役立ちます.

一般的な構造を提案するのは本当に難しいです。優れた設計は、常にビジネス ルールに基づいています。