今天研究shopnc的数据表结构，发现很多表不按照三范式来建表，很多表都是相关字段重复。
优点是很多时候不用关联表进行查询了。 缺点是不按照三范式规范，而且如果中途改一个表的字段后，相应的表也应该进行修改，但到那个时候已然发现不好改了，因为可能涉及的表太多太多了。
优点是很多时候不用关联表进行查询了。
缺点是不按照三范式规范，而且如果中途改一个表的字段后，相应的表也应该进行修改，但到那个时候已然发现不好改了，因为可能涉及的表太多太多了。
所以我想直到怎么取舍这个问题。
认证0级讲师
通常先考慮效能，如果冗餘一個欄位能夠減少很多關聯查詢，那麼通常會選擇冗餘，而不是去追求第三範式。 例如文章詳情頁通常會有評論數，這個評論數通常會冗餘在文章表中，而不是每次去評論表中統計。 但是反範式也有缺點：維護的欄位多了，資料可能不一致，儲存空間也大了等等。 這就要看是否能靈活運用了
一般來說，為了性能做冗餘是必須的；至於你說的如果一個表的值改影響冗餘的信息這個，一般是通過產品來規範， 要么冗餘的資訊在定義的表裡不允許更改，例如你註冊時的用戶名； 要么定義的信息改變後不對冗餘的信息做更新，例如你購買商品生成訂單時保存在訂單上的商品標題信息。
樓上說的對這都需要進行取捨
通常先考慮效能，如果冗餘一個欄位能夠減少很多關聯查詢，那麼通常會選擇冗餘，而不是去追求第三範式。
例如文章詳情頁通常會有評論數，這個評論數通常會冗餘在文章表中，而不是每次去評論表中統計。
但是反範式也有缺點：維護的欄位多了，資料可能不一致，儲存空間也大了等等。
這就要看是否能靈活運用了
一般來說，為了性能做冗餘是必須的；
至於你說的如果一個表的值改影響冗餘的信息這個，一般是通過產品來規範，
要么冗餘的資訊在定義的表裡不允許更改，例如你註冊時的用戶名；
要么定義的信息改變後不對冗餘的信息做更新，例如你購買商品生成訂單時保存在訂單上的商品標題信息。
樓上說的對這都需要進行取捨