數據庫設計 - 是否應該避免一對一的關係？

可能重複：
Is there ever a time where using a database 1:1 relationship makes sense?數據庫設計 - 是否應該避免一對一的關係？

爲了簡單起見，我會問這個問題直出：應該在數據庫設計一個一對一的關係來避免或本可接受？

我知道這個「item」的所有屬性都可以託管在一個表中，但是我覺得當通過ORM將我的數據庫設計轉換爲業務對象時，它會使具有不必要屬性的實體混亂。

通過用戶界面，希望這會畫出更好的圖片，我有一個主要的形式與所有必要的屬性。我將會有一個允許用戶點擊它的按鈕，它會調出一個新的表單來附加額外的屬性。不超過1個條目可以與主表單（實體）相關聯，即它是0..1的最終關係。

任何意見將不勝感激。

來源

2010-10-15 user118190

請記住，數據庫外觀（具有很好的拆分表）和查詢複雜性（當您突然加入所有這些表時）之間會存在折衷 – Tim 2010-10-15 05:07:04

所有項目是否都具有所有屬性？ – 2010-10-15 05:07:48

另一點是，根據您的ORM，您可以將單個表映射到多個實體。你可以使用.NET Entity Framwork 4做到這一點。最終結果 - 更好的數據庫設計和更好的代碼OO。 – RPM1984 2010-10-15 05:13:31

不，1：1的關係完全有意義。

想象一下，一個實體可以有一個充滿屬性的桶 - 其中一些實體具有這些屬性，而另一些則不具備這些屬性。

您可以將所有這些屬性作爲列包含到您的實體表中 - 但在這種情況下，大量列最終會爲空的大量條目。或者：您可以將這些「可選」屬性放入單獨的表格中，與基本實體表格建立1：1（或0：1）的關係，並且只將您的東西存儲在那裏有問題的實體確實有這些屬性。

的主要標準，以決定是否「外包」的某些屬性到一個單獨的表是：

多少屬性做這種擔憂？如果只是一兩個 - 不要費盡心思把它們放在單獨的表格中。但如果你正在談論8,10,15 - 那麼考慮它
有多少基礎實體可能具有這些可選屬性？再說一遍：如果95％的實體總是擁有所有這些屬性，那麼做這個額外的步驟是沒有意義的。如果你的實體只有一半或更少將對這些屬性 - >我肯定會考慮這樣一個表

來源

2010-10-15 05:04:12

謝謝！我的想法更符合你的想法！非常感謝您的回覆！ – user118190 2010-10-15 05:22:36

我知道這是一個古老的問題，但我有很多合法的1：1關係的例子，其中大部分都是唯一正確的解決方案：http://stackoverflow.com/questions/517417/is-there-ever- a-time-where-using-a-database-11-relationship-makes-sense/28313151＃28313151 – Tripartio 2016-01-18 19:44:57

我會避免一對一。如果沒有技術需求，那就沒有意義了。你只是爲db和額外的表和索引創建額外的連接來管理。另外，僅僅因爲你的表具有所有的字段並不意味着你的對象必須這樣做。

來源

2010-10-15 05:02:47

良好的信息，謝謝！ – user118190 2010-10-15 05:24:01

取決於應用需求

通常情況下，我會說，一到一個關係建模爲表中的列，但是也有情況時，這是過於嚴格：

您的架構變化頻繁，應用程序可以自定義對象的屬性
性能是不是一個問題，並且您使用視圖來創建

我曾經見過1> 1的關係橫跨在垂直分片表和數據庫拆分重指數表抽象後端屬性存儲的數據佈局要求。

您可以拆分並抽象出最終得到的結果是沿着Entity-attribute-value structure ..這不是你想要的東西（增加了複雜性，性能），除非你的應用程序需要它。正如marc_s所說，你想在可能的情況下避免這種情況。

來源

2010-10-15 05:05:45

**絕對**避免EAV的 - 在這裏看到爲什麼：http://www.simple-talk.com/sql/ t-sql-programming/avoid-the-eav-of-destruction/ – 2010-10-15 05:07:25

告訴Magento;）我同意你的意見 – 2010-10-15 05:08:44

根據我的經驗，EAV的唯一藉口是當你需要運行時可修改的模式*和*有一個偏執的或阻撓的DBA，它不喜歡任何東西，只是發出DDL的安裝腳本。如果你真的在考慮EAV，那麼爲什麼不把SQL拋到板上並使用鍵值存儲或其他東西呢？ – 2010-10-15 05:15:52

如果所有項目都具有所有屬性，則有一個表格通常是有意義的。

如果有些項目只有一些屬性，有多個表是有意義的。

爲了使ORM更高效，像lazy attribute fetching這樣的東西可能會派上用場。事情是，它仍然是相當罕見的;不要擔心優化，除非你真的認爲這會是一個問題。根據定義，過早優化並不是一個有效率的時間。

來源

2010-10-15 05:10:45

良好的信息，謝謝！ – user118190 2010-10-15 05:23:42

有兩種情況，其中可能有意義：

甲塊，其可以與主實體，這使得它成爲1相關聯的可選屬性的：[0-1]的關係。當執行對象/關係映射時，這也可以用來表示子類的字段。
A 性能非規範化，當作爲物理設計的一部分完成時。如果額外的屬性很少需要，可以將它們分流到一個單獨的表中，如果需要可以加入。但是，如果您的數據庫可以使用covering index或materialized view來優化以創建經常訪問的數據子集的物理表示，則可能不需要此技術。

來源

2010-10-15 05:12:21

好的信息，謝謝！ – user118190 2010-10-15 05:23:24

數據庫設計 - 是否應該避免一對一的關係？

回答

相關問題