一、減少輸入

　　程序員都喜歡使用通配符，如：

SELECT * FROM Person

　　又或者省略字段名：

　　INSERT INTO Person VALUES('10','張飛'...)

二、捷徑會讓你迷失方向

　　對于以上代碼，如果你僅僅是在開發(fā)過程中用于查看一下數(shù)據(jù)庫信息，又或者你只是寫個小程序自己玩玩，這是沒有什么問題的。

　　但是如果一旦你習慣于這樣編寫正式生產(chǎn)環(huán)境中的代碼，那問題就隨之而來了。

　　1、破壞代碼重構(gòu)

　　如果數(shù)據(jù)庫更改了，比如增加了一列：

　　ALTER TABLE Person Add Age int

　　這下糟糕了，你程序中所有的

　　INSERT INTO Person VALUES(...)

　　語句都會報錯。

　　早使用這種隱式模式執(zhí)行INSERT時，輸入必須嚴格按照定義表時的那些列的順序，如果列變了，這條語句就會拋出一個錯誤，甚至有可能就會拋出一個錯誤，甚至有可能把數(shù)據(jù)寫到錯誤的列里面去。

　　假設原本是使用隱式模式查詢：

　　SELECT * FROM Person

　　但是加入刪掉了中間的一個列:

ALTER TABLE Person DROP COLUMN Age

　　那么加入是使用DataTable的方式裝載數(shù)據(jù)庫內(nèi)容，那么row[10]可能就已經(jīng)不是第十個。在重命名、添加、刪除列的時候，程序代碼并不能適應查詢結(jié)果的改變。如果使用了通配符，就無法預測這個查詢會返回多少行。

　　2、隱藏的開銷

　　在查詢中使用通配符可能會影響性能和擴展性。一次性查詢所獲取的列越多，客戶端程序和數(shù)據(jù)庫之間的網(wǎng)絡傳輸?shù)淖止?jié)也越多。

　　生產(chǎn)環(huán)境中的程序可能會有很多并發(fā)的查詢請求。它們都共享同一個網(wǎng)絡帶寬。太多客戶端同時查詢返回上千條記錄可能會造成阻塞。

　　3、合理使用反模式

　　在你只是為了快速地寫幾個腳本對一個解決方案進行測試，或者寫臨時SQL查詢對當前數(shù)據(jù)進行查看時，使用通配符是合情合理的。只執(zhí)行一兩次的查詢對可維護性沒有任何要求。

　　當然，輸入一張很多列的表的所有列名是很耗時的，對某些人來說，開發(fā)效率可能比程序運行效率更加重要。例如，當你開發(fā)的是較少用戶量的小公司內(nèi)部訪問程序，這時候返回數(shù)據(jù)所使用的帶寬比查詢語句本身要多得多。這時候沒必要糾結(jié)這些問題。

三、解決方案-明確列出列名

　　1、預防錯誤

　　每次查詢都列出所有你需要用到的列，而不是使用通配符或者隱式列的列表。

　　SELECT Id,Name... FROM Person
INSERT INTO Person (Id,Name,Age...) VALUES(1,'張飛',22...)

　　這樣做的好處如下：

• 　　如果這張表的某一列的位置被移動過，他不會對返回結(jié)果中這一列的位置造成影響。
• 　　如果這張表中新加入一列，它是不會出現(xiàn)在查詢結(jié)果中的。
• 　　如果從這張表中刪除一列，你的查詢會得到一個錯誤，但是直接就能夠找到問題所在，這是符合盡早出錯原則的。

　　2、減少資源占用

　　如果必須關心軟件的可擴展性和程序的吞吐量，你應該檢查一下網(wǎng)絡傳輸過程中可能造成的浪費。一旦在SQL中禁用通配符，那么就很自然地去除那些不需要的列，提高了帶寬和內(nèi)存的使用效率。

轉(zhuǎn)載于:https://www.cnblogs.com/zxtceq/p/7160383.html

總結(jié)

以上是生活随笔為你收集整理的查询反模式 - 隐式的列的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。