2011-03-25 73 views
0

您可以對以下設計發表評論。 我是否正在用這種設計來破壞自己?我一直在反覆設計系統,因爲全新的要求不能在設計中被破解,所以現在我正在尋找具有最靈活系統的長期解決方案。universal db schema

有了這個設計,我可以動態地創建下面的複雜性和設計,現在我意識到實現不會很直接,所以在我花上幾天的時間之前,我想獲得一些真正的輸入。

這是常見的否定或是共同的嗎? 任何輸入將不勝感激。 schema

instance 
    firstname bob 
    lastname gates 
    scoreone 20 
    scoretwo 90 
    scorethree 
     scorethreePart1 30 
     scoreThreePart2 32 


    CREATE DATABASE uni; 
use uni; 

CREATE TABLE instance (
ID       INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
ParentID     INT DEFAULT NULL, 
FOREIGN KEY   (ParentID) REFERENCES instance(ID) ON DELETE CASCADE 
) ENGINE=InnoDB; 

CREATE TABLE keyval_connector (
ID       INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
ParentID     INT NOT NULL, 
TextKey      VARCHAR(255) NOT NULL, 
Note      TEXT DEFAULT NULL, 
UNIQUE(ParentID, TextKey), 
FOREIGN KEY   (ParentID) REFERENCES instance(ID) ON DELETE CASCADE 
) ENGINE=InnoDB; 
CREATE TABLE keyval_int (
ID       INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
ParentID     INT NOT NULL, 
Value      INT DEFAULT NULL, 
UNIQUE(Value), 
FOREIGN KEY   (ParentID) REFERENCES keyval_connector(ID) ON DELETE CASCADE 
) ENGINE=InnoDB; 

CREATE TABLE keyval_varchar (
ID       INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
ParentID     INT NOT NULL, 
Value      VARCHAR(255) DEFAULT NULL, 
UNIQUE(Value), 
FOREIGN KEY   (ParentID) REFERENCES keyval_connector(ID) ON DELETE CASCADE 
) ENGINE=InnoDB; 

CREATE TABLE keyval_double (
ID       INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
ParentID     INT NOT NULL, 
Value      DOUBLE DEFAULT NULL, 
UNIQUE(Value), 
FOREIGN KEY   (ParentID) REFERENCES keyval_connector(ID) ON DELETE CASCADE 
) ENGINE=InnoDB; 

CREATE TABLE keyval_datettime (
ID       INT NOT NULL AUTO_INCREMENT PRIMARY KEY, 
ParentID     INT NOT NULL, 
Value      DATETIME DEFAULT NULL, 
UNIQUE(Value), 
FOREIGN KEY   (ParentID) REFERENCES keyval_connector(ID) ON DELETE CASCADE 
) ENGINE=InnoDB; 
+0

除了以上提到的問題,已經低於升起,你是在執行數據庫內的一致性時爲自己設定一個痛苦的世界。不要做! – 2011-03-25 15:37:17

+0

感謝大家的意見!這正是我所期待的,我認爲你已經說服我不要走這條路,因爲實施不會那麼直截了當,除了看起來有人爲這個概念申請專利而不是進入這個領域! – user391986 2011-03-25 17:43:04

回答

3

它看起來像你要去Entity-Attribute-Value (EAV) Model,它在某些情況下有其用途。不知道您的要求的具體情況,很難說這是否是有效的用例。

1

不用告訴我們這樣一個數據庫模式應該是什麼應用程序支持,我們真的不能發表評論。但是,通常情況下,數據庫模式應該至少在某種程度上反映一個或多個特定域的應用程序和數據。

然而,爲了避免未來重構而插入一個圖層對我來說聽起來不太有吸引力,至少不是沒有明確的優勢,對於正在開發的代碼現在,例如引入更多適合您的數據的存儲模型。

正因爲如此,我能看到的是指數的一大堆(由PRIMARY KEYUNIQUE限制暗示)和外鍵,這是一個出色的方式帶來任何DB服務器到其膝蓋...

1

似乎它可以很好地存儲單個鍵值對。但是,如何搜索「第一個名字是弗雷德或羅傑,並且在一場比賽中至少得分23分」,而不必在同一張桌子上進行一連串重複的混淆連接?

你基本上忽略了關係數據庫的重點和目的,並將其純粹用作關鍵值存儲。爲此,您最好還是選擇其中一個NoSQL數據庫。

3

如果我理解你的模式,你正在做的是建立一個名稱/值存儲系統,與你想支持(日期,數字等)的數據類型特定表

這是一個完全有效的方法 - 但它帶來的問題與解決方案一樣多。例如,你不能以一種乾淨的方式真正建模數據庫模式的「關係」部分。用適度複雜的邏輯創建查詢是非常棘手的 - 想象用幾個AND,OR和IN編寫一些東西。像MIN,MAX等集合函數將很難做到。

另一個問題是,你以與其他行業不同的方式工作 - 這使得很難將新開發人員帶入團隊,或者使用標準工具/框架,如對象/關係映射工具,E/R圖等

1

正如喬所說,它看起來像你正在創建一個EAV模型。我認爲這對於稀疏數據效果最好。因此,儘量將所有實體(名字,姓氏等)共有的內容保存在一張表中,然後使用EAV模型獲取更稀疏的數據或更可能隨時間變化的屬性。

1

儘管我可以同情你爲什麼這樣思考,你可能正在爲一個痛苦的世界而努力。關係數據庫用於結構化數據,並且旨在有效地操縱它。

你有沒有看着XML數據庫

http://www.ibm.com/developerworks/library/x-comparexmldb/

我不建議任何特定的數據庫,因爲我不知道有足夠的瞭解他們