我可以採用這種數據庫設計嗎？

我有興趣瞭解創建由如下所述的數據庫支持的自定義系統的優缺點：我可以採用這種數據庫設計嗎？

它有6個表支持它。

實體：比方說，可以存在並有詳細的存儲什麼反對「物理」（希爾頓酒店，託尼的士，一個酒吧）

實體類型：一種分組/類型的實體（酒吧，飯店，餐廳）

元數據：任何描述或屬於一個實體項目（IR232PH，[email protected]，555-555-555）

細節

元數據類型：一種分組/類型的元數據的（郵編，電話，電子郵件，地址）

實體關係：的能力組的任何實體項目到另一個（ENTITY1-ENTITY2，ENTITY3）

實體關係類型：實體關係的分組/類型。

我可以看到這個模型對於類似但不總是具有相同數量的屬性的實體來說是好的。

對於所描述的實體，使用它有什麼優點/缺點？

藝術家可以在場地表演（關係類型）。
一個藝術家可以支持（關係型），另一位藝術家

會用它也能存儲更多的標準實體，如系統用戶的親/缺點是什麼？

用戶可以有最喜歡的（關係型）會場/藝術家/酒吧等
用戶可以有一個主治（關係型）事件

你會要儘可能有新聞和博客文章呢？

來源

2010-02-06 Benjamin Ortuzar

這是非常主觀的，但在我將抽象層升到您建議的位置之前，我寧願編寫我的應用程序以使用DDL來修改數據庫模式以匹配它使用的實際實體的具體方面，而不是具有抽象的靜態模式，以便能夠存儲關於任何潛在實體的數據。

從某種意義上說，IMHO，你有什麼建議已經完成了......它被稱爲關係數據庫。每個關係型數據庫管理系統都是一種軟件工具，它能夠對任何可能的實體集及其屬性進行建模，以精確模擬這些實體及其之間的關係。

來源

2010-02-07 00:05:57

現貨。另外，考慮一下爲了操縱RDBMS中存儲在RDBMS中的數據而必須使用的笨拙查詢。我不幸用維護傳統應用程序的模式設計，這是一場噩夢。 – Rowlf 2010-02-07 00:14:25

雖然你當然可以存儲在這樣的數據模型的數據中，有幾個與它的問題（至少）。

第一個問題是控制數據。當描述'旅館'時，必須定義的屬性和元數據集合是什麼？爲酒店合法輸入哪些元數據類型？與此相關的是「當我從列表中刪除一家酒店時，還有什麼我不得不刪除'？當我從列表中刪除所有酒店（並且我不想再次存儲酒店信息）時，還需要刪除哪些內容？這很嚇人地（很恐怖地）？很容易將各種不相關的雜亂無章的數據存入數據庫。

第二個問題是檢索數據。假設我想知道關於某家特定酒店的所有信息？我該如何編寫查詢？實際上，即使插入數據也很困難，但選擇它是困難的。如果我只想要三個屬性，很容易 - 如果酒店真的擁有它們全部。如果酒店只有三個指定的兩個，則更難。但假設酒店有30個屬性，這不是很多。然後這是非常困難的。

您所描述的是一種稱爲EAV或Entity-Attribute-Value數據模型的增強版本。普遍認爲這是一個「壞主意」，儘管這是一個普遍的想法。

來源

2010-02-07 00:20:20

你所描述的也被稱爲三重商店。三元組是主客體謂詞（Hotel HAS Rooms，Joe Likes HotelX等）。有運行這些東西（三重存儲實現），控制數據（如本體）和查詢它們的機制（例如SPARQL語言）。然而，這是所有相當先進的東西，並已知有可擴展性問題。儘管如此，再加上NoSQL方法（在大型文檔商店中索引所有酒店等），這是一個值得關注的有趣領域。

請參見：http://en.wikipedia.org/wiki/Triplestore。

來源

2010-02-07 00:28:44

我可以採用這種數據庫設計嗎？

回答

相關問題