Re: [討論] SQL的指令優缺點
※ 引述《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
→
10/15 18:08, , 1F
10/15 18:08, 1F
什麼樣的東西應該放到SQL
什麼樣的東西應該放到programming language
其實不太容易界定，也是爭辯不休的問題
我自己是把跟資料操作相關的動作放到SQL，其他的業務邏輯放在放在programming
language
→
10/15 18:12, , 2F
10/15 18:12, 2F
推
10/15 18:25, , 3F
10/15 18:25, 3F
推
10/15 18:36, , 4F
10/15 18:36, 4F
※ 編輯: pracinverse (114.24.213.99), 10/15/2016 18:41:44
推
10/15 18:45, , 5F
10/15 18:45, 5F
→
10/15 18:45, , 6F
10/15 18:45, 6F
推
10/15 19:10, , 7F
10/15 19:10, 7F
→
10/15 20:03, , 8F
10/15 20:03, 8F
推
10/16 14:55, , 9F
10/16 14:55, 9F
討論串 (同標題文章)