有一段時間我沒有理解的是，將列導向資料轉換為欄導向資料的過程，並非資料庫領域中完全客製化、陌生的概念。它仍然屬於關聯式抽象的範疇。或者說，它可以是。
舉例來說，假設我們有以下資料：
這代表了關聯式資料庫中的一個表格。讓我們假設這是一個關聯式資料庫中的表格，我們必須進行各種磁碟存取，才能存取資料的任何特定部分。這種表示法有一些不錯的特性。
新增一列很容易：我們可以構造一列：
然後將其添加到我們已有的列表的末尾。在磁碟上，我們可能只需要觸碰幾個頁面就可以完成。如果我們的列非常寬，包含很多欄位，這也不會真正改變。它仍然具有這個不錯的特性。
查找一列也是如此。由於一列的所有欄位都彼此相鄰儲存，因此可以非常快速地將該列從其儲存位置取出。
相反地，如果我們想計算不同寵物顏色的直方圖，我們必須讀取大量我們不關心的資料才能做到。
這是一種列導向的資料表示法。欄導向的表示法看起來會像這樣：
這具有列導向設計的所有相反的權衡：如果我們只關心顏色，我們可以非常有效地只讀取該資料。我們根本不必讀取牠們的名字。但是修改資料或讀取特定列會變得更困難。我們必須到處去完成這兩件事。如果我們想要第二列，我們必須到每個欄位的第二個索引去重建原始列。
因此，思考這種資料塑形的一種方式是，它是一種編碼層級。它存在於資料模型之下的抽象層級：其上的 SQL 引擎無法區分兩者，除非透過各種查詢的效能特性。
另一種思考這種欄式化方式是，它類似於一種極端的資料庫正規化。
與其有一個由一堆資料向量表示的寬表格，不如將欄式資料視為一組表格，這些表格都具有一個主鍵加上一個額外的屬性：
我們可以透過在 id 欄位上進行 JOIN 來輕鬆重建原始表格。
在欄式儲存表格的上下文中，您可以將主鍵視為給定資料的序位位置。
然而，id 欄位僅由陣列中的位置暗示：
我認為這種觀點的價值在於它統一了許多傳統的查詢處理操作，如投影（projections）和 JOIN，以及資料格式的操作。許多時候，您可能應該將資料格式視為查詢在邏輯上盲目的實現細節，但這是一個有用的心智模型，可以意識到「從欄式儲存重建一列」不僅僅是執行 JOIN，它就是一個 JOIN。