埋め込み可能対1対多

Question

投稿と投稿の詳細（2つの異なるエンティティ）とそれらの関係についてDzoneの記事を見てきました。その投稿とその詳細は別のテーブルにあります。しかし、私が見ているように、Post Detailは「親」Postなしでは使用できないため埋め込み可能な部分です。では、それを別のテーブルで分けるロジックは何ですか？

どちらを使用するのか、より明確な説明をしてください。

Answer 1

埋め込み可能なクラスは、その親クラスの状態を表します。したがって、あなたの例を挙げると、StackOverflow POSTは、不変で、共有するために破られないURLで使用されるIDを持っています。 http://stackoverflow.com/q/44017535/146325。スカラープロパティである一連の他の属性（状態、票など）があります。投稿が編集されると、さまざまなバージョンのテキストが表示されます（これは十分な担当者が保持しています）。それらはあなたの投稿詳細です。

「別のテーブルでそれを分離するロジックは何ですか？」

別々のテーブルに異なるものを保存することは、リレーショナルデータベースの役割です。このデータ・モデルを表す標準的な方法は、外部キーを使用して定義された関係を持つ親表POSTおよび子表POST_DETAILです。

埋め込み可能オブジェクト指向プログラミングの概念です。 Oracleは、データベース内のオブジェクト・リレーショナル構成をサポートしています。したがって、POST_DETAIL型を定義し、その型のネストした表として宣言された列を持つPOST表を作成することは可能です。しかし、それは2つの理由で悪い設計になります。

1. ネストしたテーブルを扱うためのSQLは厄介です。たとえば、POSTとその最新のテキストを入手するには、と表示するたびに、詳細のコレクションをアンブレッシュする必要があります（）。計算上、子テーブルへの参加や最新バージョンのフラグでのフィルタリングと大きく異なるわけではありませんが、最適化は困難です。
2. 子供は子供自身を持つことができます。投稿の場合、タグは編集によって異なる可能性があるため、詳細です。しかしPOSTに埋め込まれたPOST_DETAILにTAGを埋め込むと、[oracle]タグを持つすべての投稿を見つけるのは簡単でしょうか？

これはオブジェクト指向設計とリレーショナル設計の違いです。

OOは強く階層的です：すべてが何かに属しており、詳細を取得する方法は親を通じて行われます。このアプローチは、物事の単一のインスタンスを扱うときにうまく機能するため、UI設計に適しています。

共通の優先順位：同じタイプのものはすべて、他のものへのリンクとともにグループ化されています。このアプローチは、物事を扱うのに適しているので、データ管理タスクに適しています（BERLINで働く従業員、またはエンジニアであるか、ELLIOTTによって管理されているすべての従業員を見つけたいですか？）

「どちらを使用するかをより明確に説明してください。」

常にデータを別々のテーブルにリレーショナルに格納してください。 OOパターンを使用してAPIを作成するのが理にかなっている場合は、作成してください。