這的確沒有正確答案。

我最多只能說說我個人的習慣。

基本上來說，我會區分實例呈現情況，偏向用程式來處理資料。
而背景式處理。則偏向用資料庫來處理。

如果要說細一點的話。用程式處理大大的目的其實大多是組合性。
所以有可能會用多個請求處理。
但請求後認真來說並不會再次請求對應處理。有可能會緩存，有可能會另處理命令式。

而背景式處理，畢竟不需要再擔心回應的問題。
只要在承載的住的情況下。全交由資料庫運算處理。

1.若是複雜SQL語法及計算值，我會放到DB上的Store procedure運算結果後再取。
2.若是查詢DΒ join 會用view。
3.若是很簡單沒牽涉問題很複雜，直接SQL執行。

複雜查詢該以程式處理還是SQL語句處理？
您問的問題
表示資料庫也是您管的
所以要看是

1. 資料量大,使用次數
2. 多複雜?跟排程時間有關係?
3. 資料庫，效能可以吃多少?
4. AP Server 效能可以吃多少?
5. 需求端跟您交情好不好?
6. 主管是否有要求?程式規範?

每個人回答第一句應該都是看情況 XD
一般來說我是看業務邏輯複雜度

1. 邏輯單純，就SQL/VIEW做掉
2. 邏輯複雜，就拉回程式做
3. 當然遇到資料量極大的時候，就是兩個一起上了，
   不然把大量資料拉到AP處理，不是記憶體撐不住就是效能奇爛...
4. 預算多一點，硬體強一點，也是個做法
   

p.s. 也有遇過案子是不准使用store procedure的，敏感行業會覺得查不到軌跡

複雜的sql 90%我會選擇用程式處理
除了測試比較方便之外
最重要的是主機多開幾台
比處理資料庫sync簡單太多了阿阿阿阿阿

能程式邏輯解決就用程式，後續也好維護
sql語法盡量簡單

你那個強便用那個, 想挑戰便那個弱便用那個.時間經驗累積,得益是你自己

其實以方便自己開發維護為主，擅長用程式處理就可以在程式，擅長使用SQL處理就使用SQL，有蠻多東西都是先出來最後才優化，邊寫邊想著優化反而容易混亂，當然這是個人經驗，說不定有可以一心多用的人，先求有再求好。