privot多對多關系的中間表。PT5框架會自動把privot帶上。

我們需要隱藏，因為我們不需要privot，而且pritvot也不在我們模型本身，他是中間數據

另外冗余字段，我們有一個表是記錄圖片的，另一個表是記錄商品的。

我們可以在圖片你放商品圖片里的url

同時商品里放圖片id和圖片URL

這兩個字段是重復的，這就是數據冗余，我們設計數據庫是不要出現冗余信息，為啥我們用冗余呢。

主要是為了出于對查詢性能的考慮。

我們在這里做了數據冗余，我們就可以減少對圖片表的查詢，加速查詢速度！

不過推薦大家濫用數據冗余，因為數據冗余對于數據完整性，和一致性維護很困難。有兩個地方記錄相同的信息，但我們去寫入數據的時候，就需要寫入到兩個地方。最大的問題在于刪除和跟新。更新的時候一個地方的IMG改變了，要更改兩個。否則就會產生數據不一致。不過數據冗余用的還是挺多的。

在WEB開發中，除了掌握一些必要的數據庫優化技巧外，在合適的時候使用冗余字段也可以做到事半功倍的效果。比如下面這樣一個例子，有這么幾個表，是這么設計的。

• 用戶表［user］：id，userName
• 項目表［project］：id，projectName, user_id
• 版本表［version］：id，versionName，project_id
• 分類表［category］：id，categoryName，version_id
• 內容表［content］：id，text，category_id

差不多就是這樣了。看著很不錯，沒有字段冗余。也符合數據庫設計的三大范式。

那我們先提個問題，命名為問題X吧。

問題X：如果要查詢某個版本下的內容列表，sql應該是這么寫的：

select c.* from content c, category t where c.category_id=t.id and t.version_id=?

好像也沒什么問題。要怎么優化這個查詢呢？這個問題我們最后再來說。講回上面的表設計，如果有這樣一個問題。舉個例子，我要查詢內容A是否屬于用戶U，那我應該怎么做？

• 查詢內容A所屬的分類B
• 查詢分類B所屬的版本C
• 查詢版本C所屬的項目D
• 查詢項目D是否屬于用戶U，從而得出內容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.* from content c where c.version_id=?

相當簡單的sql！

以上說明，有時候，適當的數據庫冗余是個不錯的選擇。

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對腳本之家的支持。如果你想了解更多相關內容請查看下面相關鏈接