數據庫表按實體組織，還是垂直按數據級別？

Question

我希望標題清楚，請進一步閱讀，我將解釋我的意思。

我們與我們的數據庫設計師有關於高級結構的分歧。我們正在設計一個MySQL數據庫，我們有一大堆數據將成爲它的一部分。從概念上講，數據很複雜 - 有幾十種不同類型的實體（代表各種現實世界的實體，您可以將它們想象爲產品開發人員，工廠，產品，檢驗，認證等），每種實體都具有相關的特性和與彼此的關係。

我不是一個有經驗的數據庫設計師，但我知道的每件事都告訴我，首先將每個實體想象爲一個表（帶有表示特徵和填充它們的數據的關聯字段），並根據基礎關係。我見過的每一個數據庫設計都是這樣做的。

但是，數據目前是完全不同的形式。有四個表，每個表代表一個數據級別。頂級表格列出了39種實體類型，並且有一個長的字母數字字符串與其他三個表相關聯，這三個表代表所有實體（在一個表中），實體特徵（在一個表中）以及DB中所有特徵的值（在一張包含數千萬條記錄的表格中）。這是行得通的 - 我們在php中有一個基本的視圖，它可以讓您在各個關卡之間導航並查看數據等 - 但至少可以說這是非直觀的。這樣做的理由是它使數據庫的大小更小，縮短了查詢時間並使擴展更容易。但我不清楚DB的規模意味着我們應該優化這一點，比如組織的清晰度。

所以問題是：是否有這樣的結構DB的原因，它是什麼？我發現很難掌握基礎數據 - 例如，您不能以傳統的行和列格式運行表格 - 並且它隱藏了連接。但是更加「傳統」的基於實體的表格結構會產生更多的表格，在正常化後肯定會超過50個表格。哪種方法似乎更好？

非常感謝。

Answer 1

好的，我會根據我得到的評論和他們帶領我進行的更多研究來回答我自己的問題。直接的答案是肯定的，可以有一個理由來構建一個數據庫，只有很少的表，並且其中一個數據庫中的所有數據，它是一個實體 - 屬性 - 值數據庫（EAV）。這些的特點是：

• 一個非常非結構化的方法，每個事實或數據點只是倒入一個大表，有必要了解它的特性。這使得添加更多數據變得很容易，但它可能很慢並且/或者很難將其解決。 EAV針對添加數據和組織靈活性進行了優化，支付訪問速度慢，查詢困難等。

• 「長而瘦」的格式，很多行，很少的列。由於數據是具有自身特徵的「自編碼」數據，它通常用於當您知道將存在許多可能的特徵或數據點但其中大多數將爲空的情況（「稀疏數據」 ）。一個表的方法是有很多的空單元格，而是一個EAV並不真正具有細胞，只是數據點。

在我們的特定情況下，我們沒有稀疏數據，但我們確實有這種情況下，添加數據的靈活性可能很重要。另一方面，雖然我不認爲訪問速度對我們來說會很重要，因爲這不會成爲一個訪問量很大的站點，我會擔心創建查詢和表單的難度。最重要的是，我認爲這種結構對於我們的BD noobs來說是難以理解和控制的，所以我傾向於傳統模式 - 犧牲靈活性並且可能容易添加新數據以有利於清晰。而且，人們似乎也認爲，只要數據關係真正需要，大量的表就可以。所以，做出了決定。