我有以下表和數據庫：如何存儲可以同時構建或不構建的數據？
PATIENT (PATIENT_ID*, MEDICAL_EXAMINATIONS)
其中場MEDICAL_EXAMINATIONS包含由患者進行的檢查的自由文本描述。
最近，決定可以以結構化方式（分爲考試名稱，日期，結果等）以自由文本（一如既往）或以結構化方式報告體檢。
所以我想更改架構如下（字段標有星號組成的鍵）：
PATIENT (PATIENT_ID*, MEDICAL_EXAMINATIONS)
MEDICAL_EXAMINATION (PATIENT_ID*, NUMBER*, NAME, DATE, RESULT)
，但我發現這個解決方案有點不安，因爲我有同樣的信息（體檢）存儲在TWO表中。在這種情況下，查詢「選擇患者進行的所有體檢」的結果並不那麼「優雅」。
我真的不知道如何表達我的問題，但這種情況對我來說似乎很奇怪。 我不知道這個問題是從規範（我無法改變）發生的，還是有更好的方法來模擬數據的「兩個版本」。
就個人而言，我會單獨進行體檢的概念，完全從患者分成兩個單獨的表，就像這樣：
PATIENT(PATIENT_ID)
MEDICAL_EXAMINATION(PATIENT_ID,NAME,DATE,RESULT)
MEDICAL_EXAMINATION_NOTES(PATIENT_ID,NOTES)
「註釋」是在表名粗略估計，有可能是一個基於用例的更合適的名稱。
這可以讓您增加一些靈活性，因爲如果您選擇了將來的某個時間點，您可能會有多個「自由形式」考試。
因爲您擁有不同的數據結構，所以選擇這兩者總是會很麻煩。你很可能被限制到最低公分母，和他們拉出來作爲字符串，如果你想要讓他們在一起，就像這樣：
SELECT 'Name ' + NAME + ', Date ' + DATE + ', Result: ' + RESULT AS EXAM
FROM MEDICAL_EXAMINATION WHERE PATIENT_ID = @PATIENT_ID
UNION ALL
SELECT NOTES AS EXAM FROM MEDICAL_EXAMINATION_NOTES WHERE PATIENT_ID = @PATIENT_ID
更妙的是，如果這個數據庫正在備份某種業務對象，爲「自由形式」和「結構化」考試提供單獨的課程，然後提供一個通用的界面，用於表示體檢的字符串。這樣，您的業務層可以選擇單獨對待或一起使用它們。
您可以將NAME，DATE，RESULT列添加到PATIENT表。如果條件「具有自由格式或結構化數據，但不能同時擁有」，則可以添加防止違反條件的觸發器。
我會做：
將Patient.Examination自由文本字段視爲基本未處理或尚未轉錄的檢查。這個想法是，當你從自由文本字段中轉錄數據時，你從那裏刪除它並將其添加到另一個表中。
然而，這會帶來各種錯誤檢測和控制問題。醫療轉錄是一個微妙的領域（可以理解）。
可以說你可以進一步規範化，並描述每一個可能的考試，給它一個ID和其他數據，然後把考試ID放入醫療檢查實體，而不是簡單的名稱列。
但這一切都取決於您的要求。
這不是一個好的情況。一種可能更清潔一點的方法是將醫療檢查從病牀中排除（它不屬於那裏），並且醫療檢查表具有patient_id，姓名，日期，結果和free_text。如果輸入給定行的free_text值，則其他行將被忽略。這意味着，例如，您不能將日期設爲數據庫中的必需字段，但我認爲它仍比現有版本更好。
它還會給你從糟糕過渡到更好的數據路徑：1
階段：多數患者有一個描述多種考試自由文本單個關聯medical_examination行。
第2階段：大多數患者有多個相關的醫療檢查行，其自由文本描述每個單獨的檢查。
階段3：大多數患者有多個相關的醫療檢查行，每個單獨的檢查都包含結構化數據。
您可以將列註釋添加到MEDICAL_EXAMINATION表中。
它看起來像
MEDICAL_EXAMINATION (PATIENT_ID, NAME, DATE, RESULT,comment)
所以，你可以存儲在註釋欄的非結構化數據。
Joe Celko已經將關係數據庫的主要規則之一表述爲「One Fact，One Place，One Way」（有時會添加「One Time」）。擁有數據 - 非常重要的數據，從它的外觀來看 - 在數據庫中呈現兩次，存儲在兩種截然不同的時尚中，這不是一個好主意。你可以做這樣的事情：
還有什麼，你必須通過兩個不同的，可能不同意你的信息來源。
我們這裏有一個半結構化數據的例子，處理這個問題的一種方法是使用ExamDetails的XML數據類型字段。您可能有：
<root>
<ExamName></ExamName>
<ExamResult></ExamResult>
<FreeText></FreeText>
</root>
並非所有元素都必須出現在每個記錄中。您將使用您的數據庫XML功能來查詢該字段。所有市長DB（MS SQl服務器，Oracle，DB2）都可以存儲和查詢XML。
很少有更多音符：
我將不得不至少三個表：患者，醫生，考試
TABLE Patient (ID (PK), Name, other patient details...)
TABLE Doctor (ID (PK), Name, other doctor details...)
TABLE Exam (ID (PK), PatientID (FK), DoctorID (FK), Date, ExamDetails XML, more here...)
如果兩個醫生和病人剛好是人（而不是獸醫診所或房屋檢查）你可以在Person表中添加一個Person和Sub-type Patient和Doctor表格 - 這樣一來，在診所就診的醫生也很容易成爲患者。例如：
TABLE Person (ID (PK), FirstName, LastName, Phone, Address, other details common to people...)
TABLE Patient (PersonID (PK, FK), ...specific patient details only)
TABLE Doctor (PersonID (PK, FK), ...specific doctor details only)
TABLE Exam (ID (PK), PatientID (FK), DoctorID (FK), Date, ExamDetails XML, more here...)
因爲Patient和Doctor是人的類型，PersonID應該與Person表中的ID號碼相同。
這是一個困難的問題，你在這裏有幾個很好的答案，我在upvoting的過程中，我理解他們。
我的個人路徑是將自由文本檢查列從患者行中分離出來。在大多數物理模型中，它將是ntext，text或varchar（MAX）或類似的，並且您不希望它在行中佔用空間，這些類型通常將其數據存儲在行外，但無論如何，把它拿出來很好。通常情況下，我會在病人身上得到1-1。它使您的患者行更小，更易於管理。
然後，我會製作一個單獨的表格，將數據解讀，提取並標準化爲列和行，與病人進行多對一。
你說數據是同一個。如果是這樣，自由文本沒有必要保留，你可以使用規範化的考試表格（甚至可以重建原始的「自由文本」）
實際上，我通常會把自由文本作爲傳統並限制對其的訪問，並從標準化數據驅動所有視圖和更新。如果自由文本需要與規範化版本保持同步，那麼有許多技術可以處理這種觸發器，但是如果允許單個事務更改並且「自由文本」需要有一些零件改變了。
「最近，決定醫療檢查可以以自由文本（一如既往）或以結構化方式報告（分爲考試名稱，日期，結果等）」。
這讓我覺得這是一個非決定（可能是由非cognoscenti做出的）。從我所能做到的這個所謂的「決定」中，信息提供者仍然可以自由地以任何他想要的方式提供信息，結構化或非結構化。 （注：如果信息提供者被迫在「結構化」和「非結構化」之間做出明確選擇，我的回覆不適用）。
「結構化」意味着存在「佈局規則」（例如CSV ）和信息提供者必須符合的「內容規則」（例如「考試名稱必須是已知課程/考試的名稱」）。
但定義上的「非結構化」仍然意味着「信息提供者提供的任何信息，該信息總是至少滿足」非結構化「，因此根據定義，提供的任何信息總是可接受的「非結構化」的解釋。
因此，這個所謂的「允許結構化的決定」是對所有沒有任何用處。並且（考慮到我提到的警告），合乎邏輯的結論是，這個決定（這看起來完全是假的）「完全不做任何事情」是最好的選擇。
毫無疑問，你會想「但我不能那樣做」。如果你的管理層對邏輯上有根據的推理完全不敏感，你可能是對的。
PS
至於已作上述表示的「」有一個事實，一個地方，一個道」：（！暫時的）這樣的情況下可能會說明爲什麼有時需要放鬆，要「一個事實，一個地方，兩種可能的方式之一」，只是爲了方便用戶的過渡。