同じ基本クラスから派生したオブジェクトのデータテーブルを設計する最良の方法

私は、次の基本的な構造を持つデータベースを改造しようとしています。私は、それぞれが季節ごとにいくつかのEventTypesに分類される様々なイベントをホストできるPeopleを持っています。
このシナリオに沿ってデータベーステーブルを簡単に作成し、イベントとイベントタイプの関係を作成することができました。問題はすべて異なるタイプのイベントが異なるプロパティセットを持ち、多くのフィールドが選択されたEventTypeに応じてnullまたは空白になるイベントテーブルを作成しないようにしようとしています。
質問:イベントと呼ばれる基本クラスと、この基本クラスから継承したさまざまなEventTypesのオブジェクトを持つことができるように、データレイヤーを設計する最良の方法は何ですか。
(私はこれが混乱しないように願ってください、私は明確になります、ありがとう)

1

2 答え

私はあなたがイベントテーブルに一般的なものを置くことをお勧めします。特別な場合は、適切なフィールドに一致する追加のテーブルを作成します。

多くの場合、Polymorphic associationsなどの他のソリューションを使用することは可能ですが、ほとんどの人がテーブルやカラムを追加して、それらを呼び出すことはずっと簡単です。テーブルの数が増えたにもかかわらず、これが役立つ1つの例は、フィールド検証です。

すべての列が同じであった場合は、event_typeですが、多くの列が異なる場合は、いいえ。

すべてのものを実際に一般的な列または番号のついた列(yuch)にするのは良い選択肢ではありません。リレーショナルデータベースは、このような表や列に名前を付けるときには、読みやすさとメンテナンス性を考慮して最適です。

スキーマレスの非SQLオプションもあり、この種のバリエーションをサポートしています。これらは、mongoDB、Hadoop、CouchDBなどのSQL実装ではありません。

1
追加された
はい、それはスケールされます。本当に大量のデータでうまく拡張するには、データ構造が「流動的」であれば、おそらくnoSQLオプションを使用することを検討してください。
追加された 著者 Michael Durrant,
ウェブスケールですか? youtube.com/watch?v=b2F-DItXtZs
追加された 著者 BlackICE,

これを行う1つの方法は、基本プロパティーとEventType列を持つイベント表を作成し、それぞれの異なるイベント・タイプごとに異なる表を作成することです。 「基本」テーブルのEventType列は、イベントの残りのプロパティを取得するためにどのテーブルに参加する必要があるかを示します。 DALでは、基本イベントクラスのEventTypeプロパティを使用して、Factoryパターンを使用して正しいEventサブクラスを取得できます。

1
追加された