不能答非所問，所以不能離開你的問題。先不管應不應該寫上千行的SQL儲存過程。
首先，不能忘記儲存過程不是隻有SQL和臨時表。還有很重要的迴圈、分支、遊標等等。但是儘管不能忘記，勸大家還是不要用了：太慢了。
這樣的話，問題就變成了：如何優雅的在儲存過程中寫SQL?
技巧性的有：1、程式碼規範統一；2、要寫簡單易懂的註釋；3、一定要輸出日誌；4、olap任務中少用update，一般都能用join、merge來代替。等等。
還有一個思維方式的問題。寫SQL還有思維方式的問題？確實有。人在處理複雜問題的時候，自然而然的會把問題分成若干步驟來完成。但是SQL不是這樣的，一個SQL就是一句話，沒有什麼步驟可言。幾十幾百行的SQL有很多表join在一起，很多子查詢巢狀，但是沒有“先後步驟”。
要優雅的寫SQL，就先要適應這種和我們自然習慣不同的思維方式。再加上視窗函式，基本上SQL已經完全是另外一種完全不同於自然習慣的思維方式了。寫SQL的時候，要忘記分步解決問題的習慣，用SQL的思維習慣來思考問題的解法。
當然你可以把長SQL都拆成很短的，但是有些計算邏輯就是很複雜，即使只有五個表join，五個子查詢巢狀，再來五個視窗函式。你還能用自然思維習慣來寫麼？徹底切換成SQL的思維方式，才能寫出優雅的SQL。是不是因該總結一下“用SQL來思考”？這是另外一個問題了。
個人覺得，對“很長的SQL、儲存過程”咬牙切齒的兄弟姐妹，是因為不願意切換成SQL思維方式的原因。這也無可厚非，不過僅僅是咬牙切齒也沒用，要麼忍了，要麼找更好的辦法解決。有點跑題了。
不能答非所問，所以不能離開你的問題。先不管應不應該寫上千行的SQL儲存過程。
首先，不能忘記儲存過程不是隻有SQL和臨時表。還有很重要的迴圈、分支、遊標等等。但是儘管不能忘記，勸大家還是不要用了：太慢了。
這樣的話，問題就變成了：如何優雅的在儲存過程中寫SQL?
技巧性的有：1、程式碼規範統一；2、要寫簡單易懂的註釋；3、一定要輸出日誌；4、olap任務中少用update，一般都能用join、merge來代替。等等。
還有一個思維方式的問題。寫SQL還有思維方式的問題？確實有。人在處理複雜問題的時候，自然而然的會把問題分成若干步驟來完成。但是SQL不是這樣的，一個SQL就是一句話，沒有什麼步驟可言。幾十幾百行的SQL有很多表join在一起，很多子查詢巢狀，但是沒有“先後步驟”。
要優雅的寫SQL，就先要適應這種和我們自然習慣不同的思維方式。再加上視窗函式，基本上SQL已經完全是另外一種完全不同於自然習慣的思維方式了。寫SQL的時候，要忘記分步解決問題的習慣，用SQL的思維習慣來思考問題的解法。
當然你可以把長SQL都拆成很短的，但是有些計算邏輯就是很複雜，即使只有五個表join，五個子查詢巢狀，再來五個視窗函式。你還能用自然思維習慣來寫麼？徹底切換成SQL的思維方式，才能寫出優雅的SQL。是不是因該總結一下“用SQL來思考”？這是另外一個問題了。
個人覺得，對“很長的SQL、儲存過程”咬牙切齒的兄弟姐妹，是因為不願意切換成SQL思維方式的原因。這也無可厚非，不過僅僅是咬牙切齒也沒用，要麼忍了，要麼找更好的辦法解決。有點跑題了。