privot多對多關(guān)系的中間表。PT5框架會自動把privot帶上。

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

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

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

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

這兩個字段是重復(fù)的，這就是數(shù)據(jù)冗余，我們設(shè)計數(shù)據(jù)庫是不要出現(xiàn)冗余信息，為啥我們用冗余呢。

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

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

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

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

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

差不多就是這樣了?？粗懿诲e，沒有字段冗余。也符合數(shù)據(jù)庫設(shè)計的三大范式。

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

問題X：如果要查詢某個版本下的內(nèi)容列表，sql應(yīng)該是這么寫的：

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

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

• 查詢內(nèi)容A所屬的分類B
• 查詢分類B所屬的版本C
• 查詢版本C所屬的項目D
• 查詢項目D是否屬于用戶U，從而得出內(nèi)容A是否屬于用戶U

這樣的做法簡直惡劣至極不是嗎。此時你應(yīng)該已深刻意識到這種表設(shè)計弱爆之處。那怎么做呢？

冗余字段！沒錯，我們需要在表里添加冗余字段。如果在上述表（除了user表）都添加一個user_id字段，會怎么樣呢？

首先，可以確定，每個表的user_id字段的值都不會發(fā)生改變。所以，這個字段的值從一開始設(shè)定之后，就不用再修改了。

然后，我們再回到上述的問題：查詢內(nèi)容A是否屬于用戶U。現(xiàn)在的做法是這樣的：

查詢內(nèi)容A的user_id是否為用戶U的id

就一步！好簡單粗暴是吧！很爽快是吧！

只需添加user_id這個冗余字段，就很大程度地方便了編碼量，而且數(shù)據(jù)庫的查詢效率也提升N倍。還有，這個字段只需要維護一次！

現(xiàn)在知道冗余字段的威力了吧，回到問題X。怎么優(yōu)化那個業(yè)務(wù)邏輯呢？

正確的做法應(yīng)該是：在content表中，添加多一個version_id字段，可以肯定，這個字段跟user_id字段類似，只需要維護一次。

然后問題X的sql改為：

select c.* from content c where c.version_id=?

相當簡單的sql！

以上說明，有時候，適當?shù)臄?shù)據(jù)庫冗余是個不錯的選擇。

總結(jié)

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

最新評論