批評我的MySQL數據庫設計的無限動態字段

尋找一個可擴展，靈活和快速的數據庫設計'建立你自己的窗體'風格的網站 - 例如Wufoo。批評我的MySQL數據庫設計的無限動態字段

規則：

用戶只有1種的形式，他們可以建立
用戶可以創建自己的領域或者從「標準」領域
用戶1種的形式已經爲許多領域爲用戶想要選擇
值可以是另一值例如相片值同級可以具有名稱，位置，寬度，高度爲同級值

個特殊規則：

用戶可以提交自己的形式最多，每天5次
價值的日期是非常重要的
靈活性，能夠在價值報告（單用戶，所有用戶，1場，許多領域）是非常重要的 - 數據可視化（大多數將按時間順序爲基礎，例如所有用戶2009年7月的所有照片）。

表「用戶」

UID

表「爲field_user」 - 一個字段分配給一個用戶形成

FID

UID

重量 - int - 我們ED命令字段上的用戶形成

表「字段」

FID

creator_uid - INT - 字段 '創造者'

標籤 - VARCHAR - 例如電子郵件

value_type - varchar - 用於確定「值」表中的字段將被填充（例如，如果'int'，則該字段的值將數據提交到values.type_int字段中 - 以及所有其他.type_x字段將爲NULL）。

field_type - varchar - 例如'email' - 用於特殊條件，例如驗證規則

表「值」

VID

parent_vid

FID

UID

日期 - 日期

date_group - 詮釋 - 值1-5（用戶可以提交每天5種形式最大值）

type_varchar - VARCHAR

TYPE_TEXT - 文本

type_int - 詮釋

type_float - 浮

type_bool - 布爾

type_date - date

type_timestamp - timestamp

據我所知，這種方法將意味着'Value'表中的記錄將只有1條數據與其他.type_x字段包含NULL的......但從我的理解這個設計將是'最快'解決方案（減少查詢，減少連接表）

來源

2009-07-21 Chris Jacob

在OSCON昨天，Josh Berkus給了DB設計的一個很好的教程，他花了很大一部分無情地撕裂成這樣的「EAV」il表;你應該很快就能夠在OSCON網站上找到他的幻燈片，並最終在網上錄製他的整個教程（後者可能需要一段時間）。

您需要每個屬性的聯接（values表的多個實例，每個屬性要獲取或更新一個），所以我不知道「少連接表」的含義。加入同一個表的多個實例並不是一個特別快速的操作，並且您的設計使得索引幾乎不可行並且不可用。

至少作爲一項小改進，使用每種類型的單獨表來表示屬性的值（可能有些索引可能適用於這種情況，儘管MySQL對每個表的每個查詢限制一個索引，即使有些可疑）。

來源

2009-07-21 15:34:06

感謝您訪問OSCON和EAV的鏈接。 Josh提出了EAV'il數據庫場景的替代數據庫設計嗎？ – 2009-07-21 16:04:22

在SQL中實現「完全靈活的模式」沒有真正的好方法，請參閱http://www.pgexperts.com/presentations.html以獲取許多pgexperts演示文稿幻燈片的鏈接，包括OSCON 09之一（「數據庫作品「也應該有一些東西）; EBlob本質上是替代品，當然它有自己的問題（與EAVil不同）。 – 2009-07-21 18:07:54

你應該真正考慮像CouchDB這樣的無模式數據庫，像這樣的問題正是這些類型的數據庫想要解決的問題。

來源

2009-07-21 15:46:50

你知道嗎，創建表，修改，添加一列等是你可以在許多現代rdbms實現中運行的操作。爲什麼選擇EAVil？特別是如果你使用動態sql。

這不是爲了膽小鬼。我記得在波音公司實施了一個數據庫中的70,000個表格。

很明顯，動態表格創建存在缺陷，但它們也存在於EAV表格中。像同一個鍵的兩個屬性表達相同的事實。或傳遞依賴和其他規範化陷阱。那麼，爲什麼不至少代表您利用RDBMS的力量呢？

來源

2009-07-22 21:32:10

我同意約翰歐文。

與查詢EVA表相比，動態創建來自模式的查詢是一個小的代價。特別是如果桌子很大。

通常，表列被視爲「接口」。依賴於動態變化界面的設計通常很糟糕，但EAV數據是一種特殊情況，您沒有太多選擇。您必須在慢直觀查詢或動態模式之間進行選擇。

來源

2010-11-01 19:17:59 mike

批評我的MySQL數據庫設計的無限動態字段

回答

相關問題