如果一個對象有1000+以上的屬性，那麼應該如何安排數據表規畫？

01-26

如果一個對象有很多屬性，像一個人有身高、體重、血型……等1000多個選項，我有兩個選擇：
方案一：將數據分別放在20個表，每個表有50個屬性欄位，用JOIN組合成超長數據列。
方案二：將資料放在兩個表，一個放個人重要資料，如ID、姓名等，一個放其他所有數據，但用行儲存，由ID、屬性名、屬性值，每個ID約有1000行，但只有三列。
理論上，這兩個方式都可以完成任務，但是在擴充性上顯然有巨大差距，但是在實務上兩者都有看到。
你們建議在何時採用方案一，何時用方案二？

切記第三範式是底線

這是個很好的數據結構的問題，首先這種情況很少，會出現單一數據有同層級的1000個屬性，比如人的自然屬性，顯然不可能，必定能夠分層。其次我們假設這真的存在，不一定是人，總之一個實體存在A1到A1000個相同層級屬性，並且這些屬性不可再分。那麼我們要設計這個表。

第一，考慮必有屬性和非必有屬性，必有屬性必然存在，必須存儲，這個部分，無論你如何取巧，必然繞不過，二非必有屬性，就可以省略，在這個基礎上，你的方案1和2應當結合。一個表，作為必有屬性，每個欄位為一個屬性。另外一個表以前表主鍵為外鍵，按行存儲nullable屬性，這樣只有有屬性才會存儲。

第二，進一步考慮數據使用頻度，某些數據會經常使用，某些數據會不經常使用，有些數據會被組合使用，有些數據常常單獨存在，在這種情況下，為了查詢速度，進行緩存表設計，可以採取視圖緩存表並存的方式來設計。

第三，進一步考慮數據量極大的情況，這時候需要設計數據分區

第四，再進一步考慮數據讀寫有並發的情況，雖然主流資料庫都有一定程度支持，但是原生數據結構更支持的話，顯然會更好，這時候需要設計分庫

很少在知乎上看到真的有數據結構和架構的問題，看到這個問題，很欣慰。

任何一個對象都是由其它小對象組成的，所以，這個對象一定對外有它作為整體的重要特徵，把這些提煉出來，放在一起。而外面看不到的，冰山之下的，分層處理，懶載入。分層時根據小對象（小系統）來聚合某些屬性。

被邀請了，正好我在做的東西也有很多數據。

我很好奇你的什麼東西要這麼多數據，這對象是不是人呀？

人多的話用一，人少的話用二，要連sql用一

擴充性問題不大啊，excel里就是加一行或者一列

個人比較傾向於第一種方案

這樣IO會比較快

有的數據讀寫不頻繁，有的數據讀寫頻繁，如果做在一個表裡，肯定會降低效率

第二種方案不推薦，我也沒看出來有啥優點。。。（可能比較簡單易懂是唯一的優點吧）

至於你說的擴充性，這不是問題吧，直接加，然後在源碼中增加相應的邏輯不就行了？

不過我不是搞資料庫的，我是用xml來存儲數據，也沒達到你這個規模

hive做張寬表。

謝邀。。。

知外君表示不懂數據表，出國問題可以問我。

知外君友情提醒：出國要理性。

想聽更多客觀出國經驗和知識，歡迎關注本人公眾號：千里知外

存儲：重要的50個欄位放在外面；不重要的其他欄位，用map（ map& ）結構放一個欄位里，行嗎？

業務提出需求要在一個頁面中查詢各種數據

畏懼查表的時候多表join的龜速，我們用的是一個表多個欄位

mysql innodb引擎支持最大欄位上線為1017

myisam引擎最大欄位上限為2410

實際上還是趕不上業務需求，最後還是多表join，慢得要死

當然，單表我們沒有用到那麼多欄位，幾百吧

也不知道利弊如何。@ 蘿魏紫

有沒有可能使用另外一種資料庫？例如Bigtable！

查詢頻率高的欄位用第一種，頻率低的用第二種

占坑。

在下有個想法，等考慮成熟再來答。