嵌入與一對多

Question

我曾在Dzone看過關於發佈和發佈細節（兩個不同實體）和它們之間關係的文章。那裏的帖子和它的細節在不同的表格中。但正如我所看到的，郵政細節是一個可嵌入的部分，因爲它不能在沒有「父」郵政的情況下使用。那麼將其分離到另一個表中的邏輯是什麼？

請給我一個更清楚的解釋何時使用哪一個？

Answer 1

可嵌入類表示其父類的狀態。因此，舉個例子，一個StackOverflow POST有一個不變的ID，用在一個不可破解的URL中用於共享http://stackoverflow.com/q/44017535/146325。還有一系列屬於標量屬性的其他屬性（狀態，投票等）。當帖子被編輯時，我們有各種版本的文本（這些文本被保存並且被具有足夠的代表的人可見）。這些是你的發佈詳情。

「在另一個表中分隔它的邏輯是什麼？」

因爲在不同的表中保存不同的東西是關係數據庫所做的。表示此數據模型的標準方式是父表POST和具有通過外鍵強制實施的定義關係的子表POST_DETAIL。

Embeddable是一個來自面向對象編程的概念。 Oracle不支持數據庫中的對象關係構造。因此，可以定義一個POST_DETAIL類型並創建一個POST表，其中有一個列聲明爲該類型的嵌套表。但是，這將是一個糟糕的設計，原因有兩個：

1. 用於處理嵌套表的SQL非常笨重。例如，要獲得POST和其文本的最新版本，需要在每次我們需要顯示時取消收集細節。與加入子表和過濾最新版本標誌相比，計算上沒什麼區別，但難以優化。
2. 孩子們可以自己生孩子。就帖子而言，標籤是細節，因爲它們可能因編輯而異。但是，如果您將TAG嵌入POST中的POST_DETAIL中，那麼使用[oracle]標籤找到所有帖子是多麼容易？

這是面向對象設計和關係設計的區別。

面向對象具有強大的層次結構：一切都屬於某種東西，而獲取細節的方式是通過父項。這種方法在處理事件的單個實例時運行良好，因此適用於UI設計。

關係優先級通用性：相同類型的所有內容都與其他事物的鏈接組合在一起。這種方法適用於處理各種事情，因此適用於數據管理任務（您是否希望查找在柏林工作的所有員工或工程師是誰，還是由ELLIOTT管理？）

「給我一個更清楚的解釋何時使用哪一個」

總是將數據關係地存儲在單獨的表中。如果這樣做合理，則使用面向對象模式構建API。