根據業務和發展的需求，可以實施多種不同的數據存儲方式。第一種數據布局為橫向結構。這是一種傳統的數據存儲方式。顧名思義，每條新的數據記錄都作為一行輸入到表中，表字段是橫向排列的。第二種是縱向結構。這是一種特殊的數據存儲方式，只有由鍵(Key)和值(value)組成的兩個實際數據列，以及一個(也可以是多個)識別列(ID)。
縱向vs.橫向
下面的例子是傳統的橫向表結構：
表HR
而下面這個是縱向表結構的例子，存儲的數據和上面的橫向表相同：
表 VR
我們可以看到，數據從一個3行×4數據列的矩陣(表HR)轉變成了一個12行×2數據列的矩陣(表VR)。橫向表的記錄條數與列數的乘積似乎和縱向表的行數相等。例如：3×4=12。不過，這種假設並不一定是正確的，稍後會在文中討論這個問題。
縱向數據存儲的利與弊
傳統橫向方式存儲數據可以帶有預先設定的結構和列，所以有很多優點，但也有缺點。假設我們設計的應用程序帶有一個窗體顯示區，而這個顯示區是完全動態化的，且沒有固定的字段號碼或名稱。用戶可以即時創建一個新的字段，並賦予該字段名稱和值。要怎樣才能在數據庫中長期存儲這樣的窗體呢?
又假設我們需要根據業務要求來創建一些窗體，各個窗體具有一些符合特定業務需求的不同的字段。我們要把各個窗體的數據都存儲在一個橫向結構表中，該表中給每一個字段分配一個特定的列，而每個窗體就是該橫向表的一行。經過一段時間以後，由於業務需求需要對某個窗體添加一個新的字段。為了將新字段添加到窗體中，就必須改變用戶界面和持久層邏輯，而且實際存儲的表還需要為此添加額外的列，這樣該應用程序還需要重新進行測試和調配。在一個開發人員沒有權限直接訪問數據庫的環境中，數據庫管理員團隊也要參與到表的實際修改操作當中。如果只需要修改一次也就罷了，但是如果過一段時間後又需要添加另外一個字段呢?
要解決上面提到的兩種情況，就需要使用縱向數據存儲方式，並在應用層和用戶界面上采用一種不同的動態邏輯。因為數據能夠以“鍵/值”配對的形式存儲在只有兩列的表中，並通過單一的ID的形式將數據通通綁定在一個邏輯窗體中，而且對於能夠在一個窗體中設置多少字段並沒有限制。而後，縱向表中的每個邏輯行的字段數就可以不一樣了。由此可見，縱向數據存儲結構的最大好處就是靈活性，不過也有很多弊端。
首先，雖然彈性是有了，但失去了對數據的控制權，也就是說很難維持數據的規范化。舉個例子，如果我們在一個縱向表中存儲了一個共同基金的信息，根據分析師的名字和聯系方式都能夠對這些信息做出修改;而通常情況下，這種類型的信息都是存儲在不同的表種，並通過外鍵ID連接到基金表的。而且，在縱向表中，字段的數據類型設置也會出現問題。因為在“值”這一列，只能設置成一種數據類型(例如，設置成varchar)，而所有的值都必須是這種類型的值，或者你也可以在保存和檢索操作中不停來回轉換數據類型。此外，在縱向表中不可能存儲類似於BLOB和CLOB這種特殊類型的數據。
縱向表還有一個缺點就是數據的一致性問題。將所有的列名都輸入到一個“鍵”列中，使用戶(或應用程序)能夠很輕易就把相同的數據存儲成不同的“鍵”和“值”。例如，用戶可以創建一個新字段，命名為“公司”，賦予其值為“甲骨文”;而其他用戶可能將字段名改為“企業”，而值為“甲骨文”，事實上兩個用戶的數據是相同的。
此外，要管理和操作縱向表很有難度。要找到並確定一個邏輯行，需要進行多次自連接操作。因此，很少有商業報表軟件能夠利用縱向表來生成任何有意義的報表。
例如，以上面的表為例，要從橫向表中獲取所有男性雇員的記錄，我們可以使用以下的select語句：
Select * from HR where 性別 like '男'
而要從縱向表中獲取同樣的數據，我們就需要進行自連接查詢，先獲取ID，然後獲取數據：
Select * from VR where id in
(Select id from VR
where key = '性別'
and value = '男')
很多開發人員會編寫一些特別的函數或存儲過程將縱向結構表轉換為橫向結構，只有這樣做，他們才能做出報表，並能夠更容易地使用這些數據。
縱向表分組
縱向數據存儲的變體能夠引入自定義算法把邏輯數據行聚類。這意味著可以使用兩個或以上ID列來作為分組屬性。例如：
當生成自定義報表時，可以很容易地根據第二個“分組”列來將不同的內容分割到不同的頁或不同的區域內。因此，上面的縱向表可以得到以下報表：
總結
本文為大家介紹了在數據庫表中存儲數據的兩種不同方式。雖然縱向數據布局的缺點往往會把它的優點覆蓋掉，但某些情況下為了獲得靈活性，這種縱向結構是設計數據組織結構的唯一出路。另一方面，橫向表則是管理數據庫管理系統中存儲數據的傳統模式，更易於實現數據規范化。對於軟件和數據庫架構師而言，要選擇何種設計方式來長久保存數據取決於特定的應用需求。
