我不是很有經驗的編程或腳本數據庫查詢，我也似乎越來越依賴於結果的進一步操作從寫更多的是數據庫，而不是花時間完整的查詢可以實現我的最終目標。是常見的做法，以進一步操縱代碼查詢結果
實際上，在某些情況下，我完全被對列中的值相結合和刪除行改變的結果的性質。在循環中操作代碼似乎更容易，而不是編寫更多涉及的查詢。
當然大部分的時間，我可以編寫查詢，我從服務器獲取的結果後，我究竟是如何想使用它。但是有些情況下，我運行結果進一步過濾，因爲我不知道如何在sql中完成，但編碼看起來非常簡單。
這取決於。通常，您應該讓數據庫處理數據庫擅長的事情 - 過濾，排序和連接數據。數據（業務邏輯）的複雜查詢後轉換通常應該在您的應用程序代碼中進行，而不是在查詢中進行，尤其是因爲在SQL中調試這些東西確實很糟糕，但在應用程序代碼中卻相對沒有問題。
如果你完全相信你的數據集總是非常小（比方說少於幾百條記錄）並且你的操作總是很簡單，那麼在你的應用程序代碼而不是SQL中進行操作在整體性能或可維護性方面可能沒有什麼區別。另一方面，如果你的數據集有可能在某一天增長得非常大（你應該明確地測試一下 - 用虛擬數據填充你的表來測試這個！），那麼你冒着編寫應用程序代碼的風險是難以忍受的笨重，可能會使用大量的內存來完成數據庫將爲您做的更好的事情。此時，您可能需要查看數據庫對應用程序代碼可以更高效地執行哪些操作，並儘可能合理地分配工作負載。這樣做需要測試和分析你的數據和你正在操作的操作。
最終答案？ 根據您的需求決定如何恰當地分配數據庫服務器可以有效完成的工作（使用SQL），並且可以在應用程序代碼中高效且乾淨地完成工作。
IMO，操縱代碼儘可能少。通常你可以使查詢相當接近你想要的。但是，如果你不能，在代碼中操縱數據本身並不是一件壞事。
這取決於這些行動的性質。 SQL不適合在關係查詢中無法描述的過程計算。但是，在處理大型數據集時，必須小心不要獲取太多數據以便進一步處理到客戶端，並儘可能在服務器上處理它。
一般來說，你應該做的數據操縱SQL但要儘量避免基於業務邏輯處理數據，因爲它使得它真的很難測試，可以成爲錯誤的來源。