だから私はこの悪夢（RDBMS）を持っています。ここで多くの質問をしましたが、rdbms で oo の概念を模倣することについて、答えはありませんでした ...
多くの Web サイト (フォーラム、ソーシャル ネットワークなど) には、投稿されたコンテンツに関する多くの機能があります。
コメント、いいね、共有、星などを付けることができます...
いくつかの種類の投稿 (通常の投稿、コメント、写真、質問) があり、一部の種類の投稿にはすべての機能を含めることができないと仮定すると (たとえば、星とコメントのみなど)、どの方法を使用するかを決定するのは非常に困難です。 ...
私は行くことができます ：
各投稿のエンティティ ID とエンティティ タイプを作成することにより、oo 道路上で (このエンティティ ID は各投稿テーブルで参照され、機能もエンティティ ID を参照します)。また、いくつかの整合性トリガーを作成するためにエンティティ タイプが必要です。投稿にさらに機能を追加する必要がある場合、このエンティティ タイプ フィールドは悪夢になります (いくつかの新しいエンティティ タイプを追加する必要があります)。そして、これは単純にデータの整合性を台無しにします。
または 5 倍以上の db テーブルで。これは、投稿テーブルのすべてのタイプの機能テーブルを設計することを意味します。これには、より多くの結合とより長いクエリが必要になりますが、少なくともデータの整合性やスケーラビリティに問題がないことはわかっています。
rdbms を使用する必要があります。oodbms の方法やグラフ db の方法は使用できません。
2種類のデザインからあなたは何を選びますか？または、どのようにそれをより良く設計しますか?