Normalization
該表打破了哪些規範化規則
我們以前的 DBA 已經厭倦了開發團隊頻繁請求更改數據庫模式以添加和刪除列。然後，他向開發人員建議，他將創建具有以下定義的簡單表。
+---------------+---------+ | Record Number | VarChar | +---------------+---------+ | Column Name | VarChar | +---------------+---------+ | Column Value | VarChar | +---------------+---------+因此，如果開發人員想要一個通常如下所示的表格
+-------------+---------------+-----------------+ | Employee ID | Employee Name | Employee Salary | +-------------+---------------+-----------------+ | 0001 | John Doe | 100000.00 | +-------------+---------------+-----------------+ | 0002 | Jane Doe | 110000.00 | +-------------+---------------+-----------------+ | 0003 | Jack Doe | 120000.00 | +-------------+---------------+-----------------+他們可以按以下方式添加行
+---------------+-----------------+--------------+ | Record Number | Column Name | Column Value | +---------------+-----------------+--------------+ | 1 | Employee ID | 0001 | +---------------+-----------------+--------------+ | 1 | Employee Name | John Doe | +---------------+-----------------+--------------+ | 1 | Employee Salary | 100000.00 | +---------------+-----------------+--------------+ | 2 | Employee ID | 0002 | +---------------+-----------------+--------------+ | 2 | Employee Name | Jane Doe | +---------------+-----------------+--------------+ | 2 | Employee Salary | 110000.00 | +---------------+-----------------+--------------+ | 3 | Employee ID | 0003 | +---------------+-----------------+--------------+ | 3 | Employee Name | Jack Doe | +---------------+-----------------+--------------+ | 3 | Employee Salary | 120000.00 | +---------------+-----------------+--------------+這顯然不符合氣味測試，讓我想分析一下這樣的設置會破壞什麼數據庫規範化。
這是一個可怕的模式，但它實際上並沒有破壞任何規範化規則。原因是它實際上改變了你正在建模的內容。它不是對您的數據庫建模，例如員工，而是對實體、屬性和值進行建模。
我同意大衛布朗的回答和拉馬克的評論。他們對我的分析幫助很大。
正如 Lamak 在他的評論中提到的，這樣的模型被稱為EAV 模型。儘管 EAV 模型可能不會違反任何規範化規則，但它應該主要用於對可用於描述它們的屬性（屬性、參數）的數量可能很大的實體進行建模，但實際應用於給定的數量實體比較適中。EAV 模型是一種高效的數據儲存方式，但效率低下且難以查詢。
在域的實體具有明確定義的屬性的情況下，關係模型更加優越和可取。當這樣的模型在RDBMS中實現時，使用者可以利用強大的 RDBMS 功能，如高效的儲存技術和強大的查詢能力。