3

評価したい (非常に良い、良い、普通、悪い...) 2 つのオブジェクト: 生徒と教師。どちらの設計ソリューションが優れていますか?

解決策 1:

学生(StudentID, Rating,...)

-----1--------良い-----

-----2--------悪い-----

------3-----非常に良い-----

Teachers(TeacherID、評価、...)

---1-----とても良い-----

-----2--------悪い-----

------3--------悪い-----

解決策 2:

学生(StudentID、RatingTypeID、...)

------1----------------2----------------------

------2----------------1----------------------

-----3----------------3----------------------

Teachers(TeacherID、RatingTypeID、...)

------1----------------1----------------------

------2----------------1----------------------

-----3----------------3----------------------

RatingType(RatingID, RatingDescription,...)

---1-------------とても良い---------

---2-------------------良い----

------------------3----------------悪い---------------

両方とも十分でない場合は、いくつかの提案をいただけますか? ありがとう！

4

2 に答える 2

2

解決策 2 はこれら 2 つの中で最良ですが、アプリケーションの存続期間中に複数の投票を行いたい場合は、投票の対象を特定するテーブルと、投票を保存する別のテーブルが必要です。

Student:
   id
   name
   class
   ...

Teacher:
   id
   name
   subject
   ...

voterType
   id 
   description (student or teacher)

contest:
   id
   description (ex: 1st Semester 2013)

contestVotes:
   id
   contestId
   voterType (Teacher or Student)
   voterId
   ratingTypeId
于 2013-10-27T18:12:32.050 に答える
1

提案された 2 つの解決策のうち、次の理由から、私は間違いなく 2 番目の解決策を選択します。

  • a を数値として格納するRatingと、順序付けや集計が関係する場合に便利です。この場合、文字列はほとんど役に立ちません。

  • 列Ratingを への外部キーにすることで、非常に特定の意味を持つ特定のセットの値のみを持つことができるRatingType.RatingIDという制約が適用されます。さらに、将来的にテーブルにRating列を追加して、評価に価値を追加する可能性があります。RatingType

改善案としては、ご質問いただきましたので、IS-A関係を利用した実装をご検討ください。教師と生徒は明らかに両方Personsであり、ある程度共通の属性を持っています。Person共通の属性 (名、姓、住所、電話番号など) を含むスーパークラス テーブルを作成し、 の主キーstudentsとteachers外部キーを作成しPersonsます。

評価も共通の属性であることに注意してください。だから表に出るのは当たり前Persons。もちろん、教師と生徒にさまざまな種類の評価がある場合を除いて、その場合は 2 つの異なるRatingTypeテーブルを実装する必要があります。

于 2013-10-27T18:45:57.370 に答える