Re: [討論] SQL的指令優缺點

[pracinverse (改)]

※ 引述《ripple0129 (perry tsai)》之銘言：

有感而發，分享一下我自己的想法。

: 在看過一些複雜的SQL指令後，
: 覺得這是個難以維護的東西。
: 優點自然也是有的，
: 可以少寫不少程式碼。
: 而複雜的SQL指令不外乎Join了好幾個Table，
: Where了好幾種條件。
: 想請教各位大大對於SQL的應用上，
: 單純做CRUD然後給與對應的entity物件，
: 需要Join時就是Select Table出來，
: 之後再自行用程式碼拼裝。
: 還是下達花式SQL指令降低程式碼量好？

看到複雜的SQL就覺得難以維護通常有幾個原因：
1. 你SQL功力太差
2. 當初寫這段SQL的人功力太差
3. 真的很複雜

如果看到複雜的SQL就覺得應該盡量搬到programming language來處理，其實是矯枉過正啦

之所以會覺得SQL複雜是因為
1. 寫SQL的思維和寫programming language不一樣
2. SQL雖然已經有TRY-CATCH、迴圈，條件判斷...等等功能，
   但是畢竟它不像一般programming language一樣成熟。
   (programming language有framewrok可以用，有class、template、封裝繼承多型..等
   可以你在寫程式的時候盡量地code reuse)
   很多對SQL不熟的人把一些業務邏輯寫到stored procedure裡面來，
   SQL code自然變得又臭又長。
   (曾經看過上千行的stored procedure，實在讓人不想維護)
3. 很多公司傾向不找"只懂SQL，但是對SQL非常專精的expert"


: 然後哪一種對資料庫有較輕的負擔？
: 反正規化的查詢速度優勢，
: 犧牲了正規後儲存空間以及降低了資料一致性，
: 且對於程式碼來說也降低維護性，
: 在現今環境來說值得嗎？
: 我個人的看法是維護性最高優先權，
: 在維護性低的情形下，
: 後面加入的程式碼品質可能每況愈下。
: 程式碼品質不斷降低會造成資料庫的損耗加重。
: 最後可能得不償失。
: 想了解我這樣的觀念是錯誤的嗎？

因為你是engineer，每天看程式，如果程式很髒你會很痛苦，
所以才會覺得維護性優先權最高。

如果你是PM，就不會覺得維護性的優先權最高。
優先權最高的是要能夠賣錢，
要能夠賣錢就要來看你提供的features是不是客戶想要的，
再來是performance的問題，因為用起來很慢的話，客戶會不爽，
最後才是維護性的問題。

如果你產品的賣不了錢，很快地整個project就會死了，所以也不需要維護了。



但是話說回來，這也是為什麼程式會很髒的原因之一，
因為一些methodology都會希望你趕快把產品拿到市場上去做驗證，
收集feedback之後，回來再做改進。
所以開發的時候總是把"在限定時間內，把features做出來"放在最優先。
至於code髒不髒那不是最重要的事情。反正之後再改就好。


其實程式髒還不是最可怕的，可怕的是架構髒。
程式髒還不難改。架構髒的話你想改也改不動，因為一改幾乎就是整個重寫。

更可怕的是有些架構就算你想重寫也不行，因為已經和其他產品整合在一起，
你一改代表其他產品部門也要跟著改，其他產品部門你很難叫得動。

最可怕的如果你的產品是需要release到客戶端的
萬一舊的架構客戶已經在用了，一旦新架構release出去，
客戶要同時升級2個產品，不然會fail。比方說：

product A ver. 1 <---(舊架構整合)---> product B ver. 1

改架構後
product A ver. 2 <---(新架構整合)---> product B ver. 2

所以
product A ver. 1 <---(不相容)---> product B ver. 2
product A ver. 2 <---(不相容)---> product B ver. 1

也就是說客戶如果只升級product A，或是只升級product B，就會產生不相容的問題。

這時候聰明的architect都會想出一招
"新舊架構並存"!!!
以後和我們整合都要走新的架構，但是舊的架構要留著，因為客戶已經在用了。

恩，於是程式就更髒了...

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.24.213.99
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1476525620.A.FD3.html
→ pttworld: SP不邏輯觀點的解釋是。。？
什麼樣的東西應該放到SQL
什麼樣的東西應該放到programming language
其實不太容易界定，也是爭辯不休的問題

我自己是把跟資料操作相關的動作放到SQL，其他的業務邏輯放在放在programming
language

→ pttworld: 不會寫SP和SQL不好容易兩爛，但為成因果關係是有趣的。
推 stosto: 這跟第一手的人的功力強相關阿
推 now99: 有時候是業務邏輯 每天一變 程式變髒了 也沒辦法了..
※ 編輯: pracinverse (114.24.213.99), 10/15/2016 18:41:44
推 ripple0129: 我其實想法蠻單純的，對不同Table下不同SQL指令，在
→ ripple0129: 後續維護幾乎都要trace到SQL指令，整個成本高很多。
推 neo5277: 看功能跟需求我覺得 假設是呈現的功能那最好就都放在SQL
→ pttworld: 請問SQL、PL和SP三者的關係。我提問的是SP和SQL。
推 luciferii: PM那段想到最近的魔獸世界兔子大法XD