即時給了醫院用來收集病人信息的表格的硬拷貝！該表格分爲幾個部分，每個部分都有許多是/否複選框。動態數據庫設計？
例如，部分中的一個是所述歷史記錄部分，其具有超過20名不相關的是/否字段：
吸菸者（是或否）
糖尿病（是或否）
慢性肺（是或否） 。 。 。 。 。
另一部分是具有類似下面的問題「壓力測試數據」部分：
標準測試（是/否），如果有，是什麼結果（正或負）， 如果正（什麼是（低或高，或中間）
程度...
有人問我設計一個數據庫，顯示關係表和它們之間的關係：S：S代表是長相沒有像「學生級數據庫」或「CD公司數據庫」i碰到了！這只是..我不知道..DYNAMIC：s：s
我沒有想法如何甚至開始設計這個數據庫或什麼是我應該閱讀或研究或實踐，以設計一個數據庫對於這樣的數據！
請幫助！
那麼有兩種基本的方法可以做到這一點。在任何一種情況下，您都會得到患者的病歷表，病人的身份證號碼，姓名以及可能的聯繫信息。
然後，您可以在此表格中添加列（即吸菸者列可以是1表示否，或者0表示否），並且您可以添加與患者的每個屬性相對應的一大堆列。
其他（和更好的，恕我直言）將離開患者表獨自，然後添加屬性表。屬性表將包含patientID，attributeName和attributeValue的列。因此，對於吸菸者，您需要輸入患者ID並在（id，「smoker」，1）的屬性表中添加一行並繼續添加。然後，您必須編寫查詢以從屬性表中獲取關於給定患者的所有信息，但這是另一個挑戰...
看看EAV (Entity Attribute Value) Database Design方案。
您不必專門使用它，只是爲了您的動態數據。它會使你的部分查詢變得有趣嗎？是。但購買一個令人難以置信的靈活性。順便說一下，我已經成功地使用EAV方案進行了幾項EHR/EMR項目。
在繼續在關係數據庫中進行設計之前，試着設想一下它是否易於維護。在實踐中，許多這類系統試圖破壞關係模型 - 這是非常經典的情況，你有表單，每個表單都有字段，沒有任何字段彼此相關，每個病人都有表單和字段的副本， 等等。
我強烈希望這比關係模型。看看諸如Couch DB這樣的項目，它們是以文檔爲中心的數據庫，而不是您習慣使用表和模式等進行查看的模式。
圍住CouchDB，Mnesia或其他非關係數據庫。找一本關於這個主題的書，找出用慣用方式設計這類系統的最好方法。
實際上，這些系統類似於實體屬性值數據庫，只是它們可以很好地搜索索引。
查看Martin Fowler的「分析模式」。他在爲醫療保健系統解釋一些不錯的對象模型方面做得很好。我認爲它也可以給你一些關於數據模型的好點子。
從對象開始，剩下的就會隨之而來。
你所說的 「動態」 是什麼意思？似乎你有一套相當標準的關於待存儲患者的數據。我對你的建議是模擬這些數據：患者及其屬性。不要試圖模擬問卷。用於收集數據的手段是無關緊要的，表單設計與數據庫設計沒有多大關係。
@Paul：fair'nuff，那只是其中的一個。 – 2010-12-07 19:29:06
@Matt：我知道。我自己有過那些日子。 – 2010-12-07 20:01:24
我看起來這是一個你沒有經驗的大項目。我建議你去找你的老闆，告訴他你從來沒有做過這樣的工作。我認爲在開始時坦率地比展示不起作用的設計更好。你在這裏坦率地說，你有「沒有想法」，所以在你工作的時候坦率地說。 – 2010-12-07 23:23:00