DBデザイン。継承

Question

さまざまな「エンティティ」（属性が異なる）がメッセージを送信し、他のエンティティからのパブリックメッセージとやり取りするWebアプリケーションを開発しているとします。これらのエンティティは、いくつかのタイプのものかもしれません：ユーザー、私設会社、アカデミー...

DBを設計するには、2つのオプションが考えられますが、どちらが良いかわかりません。私には起こらなかった他の良いオプションです。

オプション1：異なるテーブル内の異なるエンティティを区切ります。この場合、メッセージを格納するテーブルには、それを発行したエンティティ、ID、およびタイプを識別する少なくとも2つの列が必要です。

オプション2：すべてのエンティティを親クラスから継承させる。したがって、メッセージを格納するテーブルには、発行したエンティティのIDを指す外部キーのみが必要です。このオプションははるかに優れているようですが、問題はすべてのエンティティに共通の属性を見つけることができないため、親テーブルにidだけがあることです。

どのオプションが良いと思いますか？より良い選択肢はありますか？

PS：オプション2の場合、主キーが十分であるため、子テーブルに独自のIDがあるか、外部キーを定義する必要がありますか？

ありがとうございました。

Answer 1

私はあなたの質問を正しく理解していただきたいと思います。
複数のエンティティがあり、メッセージを公開します。私たちは、メッセージを保存する最適な設計ソリューションを見つけようとしています。

オプション1：別のテーブル内の別々の異なるエンティティ。この 場合は、メッセージがそれを公表するエンティティ、IDを特定し、発行者を識別するために、少なくとも二つの列(id , type)を持つ

を入力するために、少なくとも2つの列 を持つべき格納するテーブルは、良いデザインではありません。私たちはパブリッシャーの外部キーをカスタムメイドのソリューションに置き換えようとしているので、副作用はデータの整合性を失うことになります。存在しない出版社のIDでメッセージが保存されるのを防ぐにはどうすればいいのか考えてみてください！またはいくつかの新しいエンティティタイプが定義されるときに発生します。
正しい方法はパブリッシャーの外部キーを持つことになり、それはメッセージテーブル内にヌル可能な複数の外部キー列で終了します。それはまだid+typeのよりよい解決には評価されません。

オプション2：すべてのエンティティを親クラスから継承させる。したがって、メッセージを格納する テーブルには、それを発行したエンティティのIDに を指す外部キーのみが必要です。このオプションは、ずっと 良さそうですが、問題は、親テーブルが一つだけ、IDを持っているでしょうので、私は、すべての エンティティに共通の属性を見つけることができないということです。

私はこの方法を選択します。

私はすべてのエンティティ

メッセージ出版の本質最も明白な共有機能（属性）があるに共通の属性を見つけることができません。しかし、私は子テーブルが自分 自分のIDを持っているか、主キーとして外部キーを定義するということが必要であろう、オプション2について

...名前、登録日、ステータスなどの他の共有属性があると思いますRDBMSで十分

モデルの継承は、一つの解決策たこと：
親の主キーは、この外部キーが子テーブルの主キーでなければならない子テーブルと内の外部キーになります。

Answer 2

NoSQLが到着したことで、これらの種類の受胎問題は解決しやすくなりました。あなたが言ったように、あらゆる種類のデータ（1人の人、1人のグループまたは1人の組織に関連するWebメッセージ）を保存することができるWebがあると想像してください。

文書NoSQLデータベースがこの問題をどのように修正するかの大きな例を挙げます。すべてのメッセージを単一のコレクション/テーブルで解決できます。ここでは例を示します：

[ 
    { 
     "message": "Test message", 
     "destination": [ 
      { "type": "user", "username": "user1" } 
     ] 
    }, 
    { 
     "message": "Test message", 
     "destination": [ 
      { "type": "org", "username": "company1" }, 
      { "type": "user", "username": "user3" }, 
     ] 
    }, 
] 

もちろん、NoSQLデータベースもリレーショナルデータベースのようにIDで再生されます。前の例では、各メッセージと宛先リストの各オブジェクトにidを付けることができました。