5

オンコールスケジュールの情報を保持するためにデータベースに取り組んでいます。現在、私は次のような構造になっています。

Table - Person: (key)ID, LName, FName, Phone, Email
Table - PersonTeam: (from Person)ID, (from Team)ID
Table - Team: (key)ID, TeamName
Table - Calendar: (key dateTime)dt, year, month, day, etc...
Table - Schedule: (from Calendar)dt, (id of Person)OnCall_NY, (id of Person)OnCall_MA, (id of Person)OnCall_CA

私の質問は次のとおりです。Scheduleテーブルを使用して、dtが一意のキーである構造のままにするか、dtが一意でなく、テーブルが次のようになるように再配置する必要があります。

Table - Schedule: (from Calendar)dt, (from Team)ID, (from Person)ID

毎日複数のエントリがある、または単に使用するのが理にかなっています：

Table - Schedule: (from Calendar)dt, (from PersonTeam)KeyID - [make a key ID on each of the person/team pairings]

チームには常に誰かが電話に出ますが、一度に複数のチームに電話をかけることができます（複数のチームに所属している場合）。

完全に異なる設定でうまくいく場合は、私にも知らせてください！

助けてくれてありがとう！質問が不明な場合はお詫び申し上げます。私は速く学んでいますが、それでも毎日SQLを使用するのはかなり新しいので、悪い習慣を身に付けないように、学習するときはベストプラクティスを使用していることを確認したいと思います。

4

2 に答える 2

2

  • チームごとに 1 つの列という現在のバージョンは、おそらくお勧めできません。チームを (列挙型や同等のものとしてではなく) テーブルとして表しているため、時間の経過とともにチームを追加/削除することが予想されることを意味します。これにより、テーブルに列を追加/削除する必要があり、これは常に、いくつかの行を追加/削除するよりもはるかに大きなタスクです。

  • 2 番目のオプションは、このような問題に対する通常の解決策です。安全な選択。Schedule(teamID, personID) から PersonTeam への追加の外部キー制約をいつでも定義して、チームに属していない人にスケジュール義務を誤って割り当てないようにすることができます。

  • 3 番目のオプションは 2 番目のオプションとほとんど同じですが、PersonTeam の複合自然キーをサロゲート単純キーに交換するだけです。上記の複合キーの 2 つのコンポーネントは既に代理であるため、この追加のコンポーネントを追加しても (不変性などの点で) 利点はありません。さらに、ほとんどのDBマネージャー/ORMが適切に処理する非常に単純なNM関係（PersonTeam）を、独自の管理が必要なより複雑なオブジェクトに変えます。

オッカムのかみそりで、追加の代理キーを廃止し、2番目のオプションを使用します。

于 2012-11-04T17:49:35.843 に答える
1

私の見解では、チームの数が固定されていてかなり少ないかどうかによって答えが変わる可能性があります。もちろん、チームの名前が固定されているかどうかも問題になる可能性がありますが、それはおそらく列の命名に関係しているでしょう.

より具体的には、私の見解は次のとおりです。

ビジネス要件が常に少数の固定人数 (たとえば 3 人) でSchedule待機することである場合、任命された人物の ID を保持するすべてのチームに 1 つずつ、 3 つの列を に割り当てる方が便利な場合があります。あなたの現在の構造のように：

dt   OnCall_NY  OnCall_MA  OnCall_CA
---  ---------  ---------  ---------

をdt主キーとして使用します。

チームの数 (Teamテーブル内) も固定されている場合は、現在行っているように列名にチームの名前/指示子を含めることができますが、チームの数が 3 つ以上であり、それが単にチームの数である場合ScheduleOnCallID1これが 3 つに制限されている場合は、 、OnCallID2、などの名前を使用できますOnCallID3。

しかし、その要件が修正されたとしても、今日修正されるだけで、明日、上司が「固定数のチーム (オンコール) で作業することはもうありません」または「サポートされるチームの数を増やす必要がある」と言います。 4 つまでであり、将来的にはさらに拡張する必要があるかもしれません。」したがって、より普遍的なアプローチは、質問で切り替えることを検討しているものです。

dt   Team  Person
---  ----  ------

主キーはどこにありますかdt, Team。

そうすれば、スキーマを変更することなく、データベース レベルで待機中の人数を簡単に増減できます。

アップデート

元の回答で 3 番目のオプションに対処するのを忘れていました (申し訳ありません)。ここに行きます。

あなたの最初のオプション (現時点で実際に実装されているもの) は、すべてのチームが 1 人だけによって提示されることを意味しているようです。人/チームのペアに代理 ID を割り当て、Scheduleと の個別の ID の代わりにこれらのキーを使用するPersonとTeam、前述の「スケジュールでチームごとに 1 人」という要件を強制できなくなる可能性があります (または、少なくとも、それが証明される可能性があります)。データベース レベルではやや面倒ですが、個別のキーを使用する場合Teamは、複合キーの一部として設定するだけで十分(dt, Team)です。これで、1 日あたり 1 チーム以下になります。

また、チーム内での存在がこのように固定されている場合、つまり、個人/チームのペアへの参照によって、時間の経過とともにその人にチームを変更させるのが難しくなる場合があります。Scheduleおそらくテーブル内のチーム参照を変更する必要がありPersonTeam、その結果、履歴情報が誤って表示されることがあります。特定の日にコールバックされた人を見ると、表示されるその人のチームは、その人が現在所属しているチームではなく、現在所属しているチームになります。彼らはその時しました。

Schedule一方、 で人とチームに別々の ID を使用すると、もちろん を参照しない限り、人々が自由にチームを変更できるようになります。(Schedule.Team, Schedule.Person)(PersonTeam.Team, PersonTeam.Person)

于 2012-11-04T17:34:40.063 に答える