privot多對多關係的中間表。pt5框架會自動把privot帶上。
我們需要隱藏，因為我們不需要privot，而且pritvot也不在我們模型本身，他是中間資料
另外冗餘字段，我們有乙個表是記錄的，另乙個表是記錄商品的。
我們可以在你放商品裡的url
同時商品裡放id和url
這兩個欄位是重複的，這就是資料冗餘，我們設計資料庫是不要出現冗餘資訊，為啥我們用冗餘呢。
主要是為了出於對查詢效能的考慮。
我們在這裡做了資料冗餘，我們就可以減少對錶的查詢，加速查詢速度！
不過推薦大家濫用資料冗餘，因為資料冗餘對於資料完整性，和一致性維護很困難。有兩個地方記錄相同的資訊，但我們去寫入資料的時候，就需要寫入到兩個地方。最大的問題在於刪除和跟新。更新的時候乙個地方的img改變了，要更改兩個。否則就會產生資料不一致。不過資料冗餘用的還是挺多的。
在web開發中，除了掌握一些必要的資料庫優化技巧外，在合適的時候使用冗餘欄位也可以做到事半功倍的效果。比如下面這樣乙個例子，有這麼幾個表，是這麼設計的。
差不多就是這樣了。看著很不錯，沒有字段冗餘。也符合資料庫設計的三大正規化。
那我們先提個問題，命名為問題x吧。
問題x：如果要查詢某個版本下的內容列表，sql應該是這麼寫的：
select c.* from content c, category 程式設計客棧t where c.category_id=t.id and t.version_id=?
好像也沒什麼問題。要怎麼優化這個查詢呢？這個問題我們最後再來說。講回上面的表設計，如果有這樣乙個問題。舉個例子，我要查詢內容a是否屬於使用者u，那我應該怎麼做？
這樣的做法簡直惡劣至極不是嗎。此時你應該已深刻意識到這種表設計弱爆之處。那怎麼做呢？
冗餘字段！沒錯，我們需要在表裡新增冗餘字段。如果在上述表（除了user表）都新增乙個user_id欄位，會怎麼樣呢？
首先，可以確定，每個表的user_id欄位的值都不會發生改變。所以，這個欄位的值從一開始設定之後，就不用再修改了。
然後，我們再回到上述的問題：查詢內容a是否屬於使用者u。現在的做法是這樣的：
查詢內容a的user_id是否為使用者u的id
就一步！好簡單粗暴是吧！很爽快是吧！
只需新增user_id這個冗餘字段，就很大程度地方便了編碼量，而且資料庫的查詢效率也提公升n倍。還有，這個欄位只需要維護一次！
現在知道冗餘欄位的威力了吧，回到問題x。怎麼優化那個業務邏輯呢？
正確的做法應該是：在content表中，新增多乙個version_id欄位，可以肯定，這個欄位跟user_id欄位類似，只需要維護一次。
然後問題x的sql改為：
select c.* froiuhipermgm content c where c.version_id=?
相當簡單的sql！
以上說明，有時候，適當的資料庫冗餘是個不錯的選擇。
總結
資料庫冗餘字段
什麼是冗餘字段？在設計資料庫時，某一字段屬於乙個表，但它又同時出現在另乙個或多個表，且完全等同於它在其本來所屬表的意義表示，那麼這個字段就是乙個冗餘字段。以上是我自己給出的定義 冗餘欄位的存在到底是好還是壞呢？這是乙個不好說的問題。可能在有人看來，這是乙個很蹩腳的資料庫設計。因為在資料庫設計領域，有...
資料庫冗餘字段思考
根據資料庫設計的第三方式，在資料庫設計過程中，應該盡量消除冗餘。即設計資料庫時，某乙個字段屬於一張表，但它同時出現在另乙個或多個表，且完全等同於它在其本來所屬表的意義表示，那麼這個字段就是乙個冗餘字段。隨著企業資料量與併發量不斷的增加，冗餘欄位的存在到底是好還是壞呢？根據第三正規化而言，冗餘欄位是垃...
資料庫中的冗餘字段
在建庫的時候，尤其是複雜的資料庫，難免會出現大量的冗餘字段，出現資料冗餘 資料冗餘 在乙個資料集合中重複的資料稱為資料冗餘.資料冗餘的目的 資料的應用中為了某種目的採取資料冗餘方式。1 重複儲存或傳輸資料以防止資料的丟失。2 對資料進行冗餘性的編碼來防止資料的丟失 錯誤，並提供對錯誤資料進行反變換得...