2

私のジレンマを説明するために、まず問題の例から始めましょう (ここから盗まれました)。データベースに次のような GradStudent テーブルがあるとします。

GradStudent:
firstName
lastName
birthDate
courseAssignment
researchGrant

ただし、ティーチング アシスタントのみがコースの割り当てを持ち、リサーチ アシスタントのみが researchGrant を持つため、これら 2 つのうちの 1 つは常に null になります。明らかにこれは最適ではなく、これを行う方が良いでしょう:

GradStudent:
firstName
lastName
birthDate

TeachAsst:
courseAssignment

ResearchAsst:
researchGrant

TeachAsst と ResearchAsst には、GradStudent テーブルからの外部キー (おそらく "studentID" サロゲート) があります。

また、次のように 2 つの完全に別個のテーブルを作成することが最善ではない理由も理解しています。

TeachAsst:
firstName
lastName
birthDate
courseAssignment

ResearchAsst:
firstName
lastName
birthDate
researchGrant

同じ意味を持つ多くの属性を繰り返しているからです。

ただし、次のような共通のフィールドがほとんどない場合、2 つの異なるクラスは理にかなっています (私はそう思います)。

TeachAsst:
name
courseAssignment
payRate
numStudents

ResearchAsst:
name
researchGrant
facultyAdvisor
researchTopic

ここでは、共通の「名前」しかないので、「名前」の属性が 1 つだけの GradStudent スーパークラスを持つのはばかげているでしょうか? 転換点はどこですか？共通情報のスーパークラスを持つ時​​期や、2 つのクラスを完全に分離する時期をどのように決定しますか? TeachAsst を作成または更新するには、1 つではなく 2 つのテーブルを変更する必要があるため、スーパークラスを使用すると、ほとんどの CRUD が少し難しくなります。

別の例として、あなたが取り組んでいる DB に、さまざまな電子デバイスの情報を測定することが含まれているとします。また、カメラと携帯電話には共通の長さ/幅/高さがありますが、他の測定値のほとんどは一致しません (たとえば、カメラには音声情報がなく、携帯電話にはレンズやビューポートの測定値がありません)。 ）。そのため、少量の共通情報をスーパークラス テーブルに入れるよりも、cameraData テーブルと mobileData を完全に分離する方が簡単に思えます。どう思いますか？サブクラスの記述データのわずかな割合であっても、共通データを常にスーパークラスにまとめる必要があるという一般的な規則はありますか?

編集: 大学院生の例では、大学院生はティーチング アシスタントまたはリサーチ アシスタントのいずれかであり、役割を切り替えることはなく、両方でもどちらでもないと仮定しましょう。

4

2 に答える 2

1

私は自分自身をデータベース設計に比較的慣れていないと考えているので、これは価値があると考えてください。最初の例では、名前やその他の個人情報を含む別の「GradStudent」テーブルを実際に維持することを最初に考えました。私の意見では、将来の潜在的な変化に柔軟に対応できます。たとえば、TeachAsst または ResearchAsst に加えて、個人が保持できる別の GradStudent ロールが作成された場合はどうなるでしょうか? 次のような将来の追加の役割に対応できる「GradStudent_Relationship」テーブルを作成できます。

GradStudent_Relationship:
GradStudent_ID (fk)
ResearchAsst_ID (fk)
TeachAsst_ID (fk)
NewGradStudentRole_ID (fk)

CRUD 操作をより難しくすることに関しては、私の意見では、追加された柔軟性がその懸念を上回ります。おそらく、データベース内にトリガーを設定して、それを支援できますか?

2 番目の例については、なぜカメラに音声がないのでしょうか? 一部のデジタル カメラは、音声を含むビデオを記録しませんか? また、携帯電話にレンズやビューポートの測定がないのはなぜですか? 最近の携帯電話にはカメラが付いているものが多くありませんか?

価値のあることですが、将来的に最大限の柔軟性を維持するために、できる限り「クラス」を抽象化することが役立つ場合があります。あなたが言及したように、CRUD 操作に関してはおそらくいくつかのトレードオフがありますが、個人的には、データベース スキーマが将来の潜在的な変更を処理できることを知りたいと思っています。

これが少なくともいくらか役に立てば幸いです。

于 2009-06-17T15:55:57.697 に答える
0

GradStudentシナリオでは、次のプロパティがあります。

GradStudentは、最初にTeachAsstになり、後でResearchAsstになることができます。または、彼女は同時に両方になることができます。

この状況では、非正規化は良い考えではないかもしれません。

しかし、あなたの場合、カメアと携帯電話を測定します。彼らは決して他のものになることはありません。複雑さを軽減するために、非正規化のリスクを冒すことができると思います。

または、スキーマに従う必要がないCouchDBのようなドキュメントデータベースの使用を検討することもできます。

于 2009-06-17T14:04:28.653 に答える