privot多對多關(guān)系的中間表。PT5框架會自動把privot帶上。
成都創(chuàng)新互聯(lián)公司是一家專業(yè)提供杜爾伯特企業(yè)網(wǎng)站建設(shè),專注與成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計、H5響應(yīng)式網(wǎng)站、小程序制作等業(yè)務(wù)。10年已為杜爾伯特眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)絡(luò)公司優(yōu)惠進(jìn)行中。
我們需要隱藏，因為我們不需要privot，而且pritvot也不在我們模型本身，他是中間數(shù)據(jù)
另外冗余字段，我們有一個表是記錄圖片的，另一個表是記錄商品的。
我們可以在圖片你放商品圖片里的url
同時商品里放圖片id和圖片URL
這兩個字段是重復(fù)的，這就是數(shù)據(jù)冗余，我們設(shè)計數(shù)據(jù)庫是不要出現(xiàn)冗余信息，為啥我們用冗余呢。
主要是為了出于對查詢性能的考慮。
我們在這里做了數(shù)據(jù)冗余，我們就可以減少對圖片表的查詢，加速查詢速度！
不過推薦大家濫用數(shù)據(jù)冗余，因為數(shù)據(jù)冗余對于數(shù)據(jù)完整性，和一致性維護(hù)很困難。有兩個地方記錄相同的信息，但我們?nèi)懭霐?shù)據(jù)的時候，就需要寫入到兩個地方。最大的問題在于刪除和跟新。更新的時候一個地方的IMG改變了，要更改兩個。否則就會產(chǎn)生數(shù)據(jù)不一致。不過數(shù)據(jù)冗余用的還是挺多的。
在WEB開發(fā)中，除了掌握一些必要的數(shù)據(jù)庫優(yōu)化技巧外，在合適的時候使用冗余字段也可以做到事半功倍的效果。比如下面這樣一個例子，有這么幾個表，是這么設(shè)計的。
差不多就是這樣了?？粗懿诲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)該怎么做？
這樣的做法簡直惡劣至極不是嗎。此時你應(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倍。還有，這個字段只需要維護(hù)一次！
現(xiàn)在知道冗余字段的威力了吧，回到問題X。怎么優(yōu)化那個業(yè)務(wù)邏輯呢？
正確的做法應(yīng)該是：在content表中，添加多一個version_id字段，可以肯定，這個字段跟user_id字段類似，只需要維護(hù)一次。
然后問題X的sql改為：
select c.* from content c where c.version_id=?
相當(dāng)簡單的sql！
以上說明，有時候，適當(dāng)?shù)臄?shù)據(jù)庫冗余是個不錯的選擇。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，謝謝大家對創(chuàng)新互聯(lián)的支持。如果你想了解更多相關(guān)內(nèi)容請查看下面相關(guān)鏈接
重慶分公司
重慶分公司
