使用 StoredProc 會讓產品交付後
客戶很容易明確的知道資料庫存取邏輯
當資料庫被駭客攻擊的時候，也很容易知道該如何下手
客戶端開發人員會很明顯知道 sp_AddProduct 使用來建立商品資料
駭客很輕易的知道 sp_UpdateProductSellPrice 是用來修改商品售價的
對用戶端開發人員而言，大部分的產品皆會附上應用程式的原始程式碼
就算今天不使用 StoredProc 撰寫，還是可以從原始程式碼中取得資料庫查詢
就安全性而言，資料庫被駭客進入就是件嚴重的事情
若今天駭客取得的資料庫帳號權限為該資料庫的擁有者 db_owner
相信要破壞資料表內容的話不需要去呼叫 StoredProc 這麼麻煩
應著重於如何讓可能會被外洩的資料庫帳號權限越小越好
當然：使用 StoredProc 進行限制會是其中一個方法
嗯!! 作者知道錯誤...但解答的方法還是還是很奇怪，因為並沒有改進整個設計模式...
作者設計方法 >> 以程式方式去與 SQL Server 進行 Connection 並在 C# 下達 TSQL 語法，並以 ADO.NET EF 來接...
即然文章內容己說明會從原始碼取得資料庫查詢，那是不是就將 TSQL 不要寫到程式碼裡面，看看是另外透過 API 來改進其設計方法呢??
我會這麼回答 >>
現行以 「程式開發」 技術與撰寫都必須跟「資料庫」 結合，交付出程式後並明確告知客戶 "千萬別任意提供給不相關之人碰到原始碼與資料庫" 將有可能有機會被駭客與不相關人士(非當時設計公司)來偷取資料。
現在設計程式應該要改變。不管任何 前端、後端、行動平台 應該都必須透過 WebAPI 的方式來存取資料，不應該再透過 程式直接與資料庫進行串接與連線的行為。 只能透過 WebAPI 來接收與傳送 JSON 來進行資料展示與處理，WebAPI 加強相關認證處理與防護之設計，被駭客攻擊時爭取時間來處理問題，並加以改進問題以防再有機會被攻擊...
WebAPI 的好處理
WebAPI 的設計將可以脫離思考與考慮 "前端、後端、行動平台" 的設計 只提供所需的資訊 並將改善無相關的資料的存取動作。
"前端、後端、行動平台" 等端點的程式，只要設計 "專案需求" 的介面與流程，任何對於資料的處理一概交由 WebAPI 來處理與解決，程式人員將可以更 "專注" 設計出正確的畫面與 Debug。
專注資料庫的設計與資料正規化
iThome鐵人賽
看影片追技術