程序員與數據庫中的設計實例分析

程序員與數據庫中的設計實例分析，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

個人對程序員是充滿無比的崇敬和敬仰的，這輩子沒做程序員是我最大的遺憾。他們創造這這個世界，的確是偉大的。

在程序開發的SQL 存儲過程中有這樣一個想法，就是我只要完成功能就可以了，的確，數據量小完成功能就好了，我可以將我的存儲過程寫成一個 “方法論”，來回的調用，也可以將我的存儲過程，寫成一部 “韓國連續劇”，或者一部日本的“貞子”。

為何這樣說，因為在我閱讀過的存儲過程中，真的是有“貞子的”， 基本上都以完成功能為主，其他的，其他的剩下的都是“貞子”。

你見過一個存儲過程，從頭倒下，全部都是 insert into  select  ..case...when  when  join.... join where.....  group by  order by  

你是否見過一個存儲過程中，充斥著 update ... set .....   where  xxx exist (select ...........)  

我估計你是見過的，并且在程序員的眼里, whatever ，你語句提供我這樣寫，我就可以這樣寫，而且我功能完成的不錯，我有什么問題嗎？

下面就是某財務軟件公司設計的 “觸發器”

我也希望我在別人心目中是 NICE ,KIND , be a gentleman.

但我對這樣的程序設計和對數據庫根本就不懂的行的設計，深表遺憾，如此設計，等待著的是客戶的抱怨和甚至是憤怒。

和同事們針對此事，討論了一番，觀點一致，從邏輯的設計，到代碼的形成，都只能持深表遺憾的情感和態度。因為我們的客戶絕對不是, 心情平靜的，佛系的客戶，當你的系統慢的要死的時候，他們必然換一張臉，回答到， 不是我的問題喲，系統太慢，我都工作不了呢？

在費勁心力后，最后得到就是這樣一個“回復”， 我想DEVELOPERS 的心情一定有上萬只 “羊駝” 飛過。

可問題是，開發的時候，如果你想到最終的結果，你還會做如下的事情嗎？

1 update 語句 后面跟一堆的條件，關聯表，并且在UPDATE之前就要耗時很長.

2  insert into  select  語句，后面要跟一堆的各種表的JOIN ，各種的判斷，耗時很長

3  不盡量避免游標的使用，通篇的游標+ 循環（還是在內部）

4  一堆的 if else  if else ,仿佛進入了迷宮

5 在插入的端口，進行極為復雜的TRIGGER 設計

終上所述，陷入了一個怪圈，數據庫的程序設計寫的就像一部 “韓國 108” 集的電視劇。

那怎么避免這樣的問題

1 UPDATE 就好好的UPDATE  后邊別跟一堆的條件，UDPATE 一定要快，你可以將你需要的在UDPATE 后處理的判斷，先進行一個select 將其格式化，變量化，等等，這并不是多難的事情，但你的客戶，就不會因為系統緩慢的運行，將你推到 “懸崖”。

2 INSERT 請就好好的INSERT  INSERT INTO  在大型系統里面不應該被存在，如何處理見上

3 游標，如果實在沒有辦法，那就用，不頻繁使用沒問題，否則祈求，客戶別投訴。

4  關于TRIGGER 的設計，在很多系統都被禁用，當然我們應該具體問題具體分析，但上面圖上那樣的ORACLE TRIGGER 設計，我真的很無語。

那存儲過程里面為什么要存在臨時表，原因如下

，

1 復雜的多表查詢中，數據庫的優化引擎在牛B ，他也有算錯的時候，無論是因為統計數據的錯，還是語句寫法的錯，復雜的查詢，如果變成多個簡單的查詢，都是沒有壞處的，那如何變成簡單的查詢，承接中間的結果，自然是要用臨時表了。

2 臨時表可以在加索引，提高查詢的效率（部分數據庫還有 內存表）

3既然是臨時表，其中的結果集應該不是很大，如果很大那就是另外一個話題了。

所以在大型系統中，請盡量將操作DML的操作與 SELECT 的操作分開，不要insert  select  , update  select ，這樣不好，也容易帶來更多的問題，和復雜的鎖。

關于程序員與數據庫中的設計實例分析問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。