數據庫設計的另一種方法：「垂直性」

我想問一個有數據庫設計經驗的人。這是我的想法，我不能評估這種方法的深層結果，比如說，共同的問題。我很欣賞你事先評論...數據庫設計的另一種方法：「垂直性」

試想：
- 患者在醫院
- 每一位患者應該有：
1.個人信息 - 姓名，街，SecurityID，聯繫人，還有更多（

personaldata_tbl
0：各種形式（也隨時間變化）堆

通常我會設計表病人pesonal數據 - 這可能隨着時間的推移）
2.個人記錄被改變| ID | SecurityID |名稱|姓氏| | TimeOfEntry

以及程序中每個表單的類似表格。這可能是一項非常艱鉅的任務，因爲它可能會達到數百個這樣的表格。除此之外，他們的人數可能會越來越多。是的，所有這些應該是關係連接，例如：

我的意圖是將2D表格還原爲單個1D表格 - 關於患者的所有數據都將存儲在一張表格中！其他表格將描述（參考）在主表中存儲什麼類型的數據。看看這個：

data_info_tbl
| ID |說明|
| 1 |名稱|
| 2 |姓氏

patient_data_tbl
| ID | patient_ID | data_info_ID | form_ID | TimeOfEntry |值
| 1 | 121 | 1 | 7 | 17.12.2011 14:34 | John
| 2 | 121 | 2 | 7 | 17.12.2011 14:34 |史密斯

的主要原因，爲什麼這種方法吸引我的是：
- 簡單
- 沒有表叢林

反政府 - 存儲與適當的規範和精度
任何數據的能力： - SQL查詢在某些情況下可能會有問題
- 應該有可靠的算法來刪除，更新，插入數據（一種方式是動態創建表，對其執行操作並最終存儲它） - 不會使用數據集控件。

那麼你會說什麼？

thanx您的時間和答案

來源

2011-12-17 lyborko

我伯特·埃文斯不同意（因爲我不覺得這是非常有效的意義上）。

首先，我不清楚你想要解決什麼問題。這三個「有利於」你列出：

簡單
任何數據存儲與適當的規範和精密
沒有表叢林能力

並不真正使有很大的意義如果應用程序很小，如果它不是（例如您在示例中提到的醫院記錄），當您開始考慮這種情況時，任何可能的「收益」都會丟失，這會使得任何類型的查詢非常低效，並且人員操作員試圖設計報告，數據提取或者擴展數據庫將不得不付出很多額外的努力。

例如：我想你的醫院患者有一個地址，因此有一個郵政編碼......你是否考慮過要在郵政編碼/狀態表上創建索引索引的循環？

另一個例子：只要你意識到病人可能有一箇中間名，並在形式上它將放在名和姓之間，你會怎麼做？重新編號所有姓氏字段？或將中間名稱放在堆的底部，以便表單必須重新添加特殊邏輯以顯示在「正確」位置？

您可能想要檢查一些SQL DB的替代品，例如基於XML的數據存儲，甚至是MUMPS，但我確實看不到您提出的方法會帶來任何好處（並且請考慮我曾見過過度熱心的DBA在設計一個由Oracle DB支持的Web應用程序時嘗試做類似的事情：網頁上的每個字段/標籤/圖像只對數據庫中的基於序列的ID記錄提供數字引用，從而使整個Web應用程序這是一場夢魘 - 所以我不僅僅是一個「純粹主義者」）。

來源

2011-12-17 10:47:19

1.通過數據提取的額外努力 - 正確。特別是在哪裏和OR操作可能難以執行。 – lyborko 2011-12-17 12:09:27

我沒有看到有關郵編的任何困難，既不是「中間名」的問題。我不確定，如果你完全理解我。中間名會得到下一個data_info id，如果將它放在姓氏旁邊的表單上或其他地方，則無關緊要。 – lyborko 2011-12-17 12:26:29

最明顯的問題。。。

你失去了對尺寸的控制。「值」列必須足夠大以容納您使用的最大類型，在一般情況下，該類型必須是一個blob。（醫院數據庫中的X射線圖像）。

你丟失了數據類型。例如，PostgreSQL包括數據類型「點」，位串，互聯網地址，cidr地址，MAC地址和UUID。將所有值存儲在單一類型的列中意味着您將失去內置於特定數據類型中的所有類型安全性。

您失去了約束。一些整數需要限制在1到10之間，其他整數在1000到3000之間。一些文本字符串需要全部是數字（郵政編碼），一些需要是特定的alpha和數字（輪胎尺寸）組合。

您失去可擴展性。如果一個人的醫療記錄中有1000個屬性，則每個人的數據在表中將佔用1000行。如果您擁有100,000名患者 - 即使在Microsoft Access和SQLite中也可以輕鬆管理，那麼您的表格會突然從可管理的100,000行增加到100,000,000行。任何執行表掃描的查詢都必須每次掃描1億行。任何需要返回的單個查詢，例如30個屬性都需要30個連接。

你的建議是EAV anti-pattern。（從幻燈片30開始。）

來源

2011-12-17 11:47:58

數據庫設計的另一種方法：「垂直性」

回答

相關問題