等,隨著時間流逝這個Stored Procedure 就慢慢變成了哥吉拉。 ⠀ 2. 由於SQL Server 的改進,Stored Procedure precompiled 的優點早已消失。 ... <看更多>
「stored procedure優缺點」的推薦目錄:
- 關於stored procedure優缺點 在 Re: [討論] SQL的指令優缺點- 看板Soft_Job - 批踢踢實業坊 的評價
- 關於stored procedure優缺點 在 我不了解,在這樣的背景之下我個 的評價
- 關於stored procedure優缺點 在 CTE,Cursor,Table Variable,Temporary Table,Stored ... 的評價
- 關於stored procedure優缺點 在 程式導師實驗計畫第三期 的評價
- 關於stored procedure優缺點 在 sql view效能-Dcard與PTT討論推薦|2022年07月 的評價
- 關於stored procedure優缺點 在 sql view效能-Dcard與PTT討論推薦|2022年07月 的評價
- 關於stored procedure優缺點 在 醫院行政面試dcard 的評價
stored procedure優缺點 在 CTE,Cursor,Table Variable,Temporary Table,Stored ... 的推薦與評價
優點. 用於Stored Procedure 時,不需要每次Recompile,速度較快; 比照Local Variable,Scope 定義明確,在不需要時就立刻會被清除; Transaction Lock ... ... <看更多>
stored procedure優缺點 在 程式導師實驗計畫第三期 的推薦與評價
你知道什麼是Stored procedure 以及如何使用 ... 來說就是把一個程式碼裡面的物件跟資料庫的物件做映射,優點就是當你操作程式裡的物件時,就會改到資料庫裡的資料。 ... <看更多>
stored procedure優缺點 在 sql view效能-Dcard與PTT討論推薦|2022年07月 的推薦與評價
找sql view效能在Dcard與PTT討論/評價與推薦,提供sql view優缺點,sql view用法,SQL view ... Stored Procedure 效能-臉書推薦/討論/評價在PTT、Dcard、IG整理一次看. ... <看更多>
stored procedure優缺點 在 sql view效能-Dcard與PTT討論推薦|2022年07月 的推薦與評價
找sql view效能在Dcard與PTT討論/評價與推薦,提供sql view優缺點,sql view用法,SQL view ... Stored Procedure 效能-臉書推薦/討論/評價在PTT、Dcard、IG整理一次看. ... <看更多>
stored procedure優缺點 在 醫院行政面試dcard 的推薦與評價
... 例如各種JOIN、Key 和Index、Transaction、Stored Procedure、aggregate ... 會請你自我介紹,你的優缺點,別人眼中的你,想去哪些單位(為什麼想 ... ... <看更多>
stored procedure優缺點 在 Re: [討論] SQL的指令優缺點- 看板Soft_Job - 批踢踢實業坊 的推薦與評價
※ 引述《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
什麼樣的東西應該放到SQL
什麼樣的東西應該放到programming language
其實不太容易界定,也是爭辯不休的問題
我自己是把跟資料操作相關的動作放到SQL,其他的業務邏輯放在放在programming
language
... <看更多>