privot多對(duì)多關(guān)系的中間表。PT5框架會(huì)自動(dòng)把privot帶上。
我們需要隱藏，因?yàn)槲覀儾恍枰猵rivot，而且pritvot也不在我們模型本身，他是中間數(shù)據(jù)
另外冗余字段，我們有一個(gè)表是記錄圖片的，另一個(gè)表是記錄商品的。
我們可以在圖片你放商品圖片里的url
同時(shí)商品里放圖片id和圖片URL
這兩個(gè)字段是重復(fù)的，這就是數(shù)據(jù)冗余，我們?cè)O(shè)計(jì)數(shù)據(jù)庫是不要出現(xiàn)冗余信息，為啥我們用冗余呢。
主要是為了出于對(duì)查詢性能的考慮。
我們?cè)谶@里做了數(shù)據(jù)冗余，我們就可以減少對(duì)圖片表的查詢，加速查詢速度！
不過推薦大家濫用數(shù)據(jù)冗余，因?yàn)閿?shù)據(jù)冗余對(duì)于數(shù)據(jù)完整性，和一致性維護(hù)很困難。有兩個(gè)地方記錄相同的信息，但我們?nèi)懭霐?shù)據(jù)的時(shí)候，就需要寫入到兩個(gè)地方。最大的問題在于刪除和跟新。更新的時(shí)候一個(gè)地方的IMG改變了，要更改兩個(gè)。否則就會(huì)產(chǎn)生數(shù)據(jù)不一致。不過數(shù)據(jù)冗余用的還是挺多的。
在WEB開發(fā)中，除了掌握一些必要的數(shù)據(jù)庫優(yōu)化技巧外，在合適的時(shí)候使用冗余字段也可以做到事半功倍的效果。比如下面這樣一個(gè)例子，有這么幾個(gè)表，是這么設(shè)計(jì)的。
- 用戶表［user］：id，userName
- 項(xiàng)目表［project］：id，projectName, user_id
- 版本表［version］：id，versionName，project_id
- 分類表［category］：id，categoryName，version_id
- 內(nèi)容表［content］：id，text，category_id
差不多就是這樣了?？粗懿诲e(cuò)，沒有字段冗余。也符合數(shù)據(jù)庫設(shè)計(jì)的三大范式。
那我們先提個(gè)問題，命名為問題X吧。
問題X：如果要查詢某個(gè)版本下的內(nèi)容列表，sql應(yīng)該是這么寫的：
select c.* from content c, category t where c.category_id=t.id and t.version_id=?
好像也沒什么問題。要怎么優(yōu)化這個(gè)查詢呢？這個(gè)問題我們最后再來說。講回上面的表設(shè)計(jì)，如果有這樣一個(gè)問題。舉個(gè)例子，我要查詢內(nèi)容A是否屬于用戶U，那我應(yīng)該怎么做？
- 查詢內(nèi)容A所屬的分類B
- 查詢分類B所屬的版本C
- 查詢版本C所屬的項(xiàng)目D
- 查詢項(xiàng)目D是否屬于用戶U，從而得出內(nèi)容A是否屬于用戶U
這樣的做法簡(jiǎn)直惡劣至極不是嗎。此時(shí)你應(yīng)該已深刻意識(shí)到這種表設(shè)計(jì)弱爆之處。那怎么做呢？
冗余字段！沒錯(cuò)，我們需要在表里添加冗余字段。如果在上述表（除了user表）都添加一個(gè)user_id字段，會(huì)怎么樣呢？
首先，可以確定，每個(gè)表的user_id字段的值都不會(huì)發(fā)生改變。所以，這個(gè)字段的值從一開始設(shè)定之后，就不用再修改了。
然后，我們?cè)倩氐缴鲜龅膯栴}：查詢內(nèi)容A是否屬于用戶U?，F(xiàn)在的做法是這樣的：
查詢內(nèi)容A的user_id是否為用戶U的id
就一步！好簡(jiǎn)單粗暴是吧！很爽快是吧！
只需添加user_id這個(gè)冗余字段，就很大程度地方便了編碼量，而且數(shù)據(jù)庫的查詢效率也提升N倍。還有，這個(gè)字段只需要維護(hù)一次！
現(xiàn)在知道冗余字段的威力了吧，回到問題X。怎么優(yōu)化那個(gè)業(yè)務(wù)邏輯呢？
正確的做法應(yīng)該是：在content表中，添加多一個(gè)version_id字段，可以肯定，這個(gè)字段跟user_id字段類似，只需要維護(hù)一次。
然后問題X的sql改為：
select c.* from content c where c.version_id=?
相當(dāng)簡(jiǎn)單的sql！
以上說明，有時(shí)候，適當(dāng)?shù)臄?shù)據(jù)庫冗余是個(gè)不錯(cuò)的選擇。
總結(jié)
以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。如果你想了解更多相關(guān)內(nèi)容請(qǐng)查看下面相關(guān)鏈接
您可能感興趣的文章:- sql與各個(gè)nosql數(shù)據(jù)庫使用場(chǎng)景的講解
- 數(shù)據(jù)庫語言分類DDL、DCL、DML詳解
- 詳解數(shù)據(jù)庫_MySQL: mysql函數(shù)
- MySQL數(shù)據(jù)庫中CAST與CONVERT函數(shù)實(shí)現(xiàn)類型轉(zhuǎn)換的講解
- mysql 8.0.15 安裝圖文教程及數(shù)據(jù)庫基礎(chǔ)
- SQL SERVER 數(shù)據(jù)庫備份代碼實(shí)例
- PostgreSQL數(shù)據(jù)庫中窗口函數(shù)的語法與使用
- Mysql主從數(shù)據(jù)庫(Master/Slave)同步配置與常見錯(cuò)誤
- PHP單例模式數(shù)據(jù)庫連接類與頁面靜態(tài)化實(shí)現(xiàn)方法
- 如何在一個(gè)千萬級(jí)的數(shù)據(jù)庫查詢中提高查詢的效率?
