database - 継承のないデータベース設計

Question

私は私のクライアントのために次のスキーマを思いついた。ここでは、特に注文明細について何か見落としがありますか。継承を使用する必要があります。このサイトでは、コース、レッスン、ギフトカードのみを注文できると確信しています。それだけです。

フィードバックをいただければ幸いです

Answer 1

デザインに関する私の考え：

1. Courses、LessonsおよびGiftCards可能な購入オブジェクトのテーブルがOrderLinesあり、各テーブルの ID が含まれています。ただし、顧客が と を購入する場合はLesson、GiftCard注文で 2 行として表示する必要があります。また、クライアントがより多くのオブジェクトを取引したい場合はどうしますか?

   したがって、この部分を次のように再設計する方がよいと思います。

   • OrderLinesに名前を変更しOrderItemsます。
   • ItemType3 行のテーブルを追加: Courses、Lessons、GiftCards;
   • Itemsフィールドを持つテーブルを追加し(ItemId, ItemType, Title, Price, LanguageCode, SortOrder, etc.)ます。

   Lessonsこのようにして、 だけでなく、考えられるすべてのアイテムにレビューを追加することもできます。

   詳細のフィールドを保持するための好ましい方法を考え出す必要がありますItems。現在、多くのフィールドCoursesをLessons共有しているため、それらすべてを新しいテーブルに移動するのが合理的かもしれません。そのItemsようなフィールドは にも有効であるように思われるからですGiftCards。また、 for などの特定の詳細がある場合は、特定のテーブル ( withなど)や、他のタイプとは共有されない一連の特別なフィールドをGiftCards追加できます。GiftCardItemsItems.idItem

2. ちょっとした注意:Usersこのテーブルには顧客とサポートの両方が含まれると思われるので、いくつかのテーブルに分割します。これは、このテーブルが大きくなる可能性があることを意味します (予想される顧客の数によって異なります)。テーブルの行数が増えると、単一のテーブルで非常に多くのフィールドを維持することが問題になる場合があります。

そして、私はマットに同意します — 要件なしで何かを言うのは難しいです.

Answer 2

クライアントからの要件を知らずに判断するのは非常に困難です。すべてがうまくいっているように見えますが、要件のドキュメントがなければ、クライアントが望んでいるものをすべて含んでいるかどうかはわかりません。