それぞれのシステムの強みを生かしていきたいと思います。
集約、結合、およびフィルタリングロジックは、明らかにデータレイヤーに属します。ほとんどのDBエンジンには、それを実行するための10年以上の最適化があるだけでなく、DBとWebサーバー間でシフトされるデータを最小限に抑えることができるため、より高速です。
一方、私が使用したほとんどのDBプラットフォームは、個々の値を操作するための機能が非常に貧弱です。日付の書式設定や文字列の操作はSQLにぴったりで、PHPで作業する方がよいでしょう。
基本的に、各システムをその目的に合わせて使用します。
保守性の観点から、どこで何が起こるかが明確である限り、これらをロジックのタイプに分離することは、多くの問題を引き起こさないはずであり、確かに利点を超えるには十分ではありません。私の意見では、コードの明確さと保守性は、すべてのロジックを1か所にまとめることよりも一貫性に重点を置いています。
Re：具体例...
-
これもあなたが言及していることではないことを私は知っていますが、日付はほとんど特別な場合です。システムによって生成されたすべての日付がWebサーバーまたはデータベースのいずれかで作成されていることを確認する必要があります。そうしないと、dbサーバーとWebサーバーが異なるタイムゾーンに設定されている場合にいくつかの厄介なバグが発生します（これが発生するのを見たことがあります）。たとえば、
createdDateがあるとします。 デフォルトがgetDate()の列 これは、挿入時にDBによって適用されます 。レコードを挿入する場合は、PHPで生成された日付を使用します （例：date("Y-m-d", time() - 3600)、過去1時間に作成されたレコードを選択すると、期待どおりの結果が得られない可能性があります。どのレイヤーでこれを行う必要があるかについては、例のように、列のデフォルトを使用できるDBを使用することをお勧めします。 -
ほとんどのアプリでは、これをPHPで行います。名と名前の組み合わせは、敬礼、タイトル、ミドルイニシャルが必要になることもあることに気付くまでは簡単に聞こえます。さらに、ユーザーの名前、名前、および敬礼+名前+名前の組み合わせが必要な状況になることはほぼ間違いありません。それらをDB側で連結すると、実際にはかなりマイナーですが、より多くのデータを移動することになります。
-
依存します。上記のように、それらを別々に使用したい場合は、パフォーマンス面でそれらを別々に引き出し、必要に応じて連結することをお勧めします。とは言うものの、あなたが扱っているデータセットが巨大でない限り、おそらく他の要因（あなたが言うように、保守性のような）がより関係があります。
経験則：
- インクリメンタルIDの生成はDBで行う必要があります。
- 個人的には、DBによって適用されるデフォルトが好きです。
- 選択する場合、レコード数を減らすものはすべてDBが実行する必要があります。
- 通常、データセットのDB側のサイズを縮小することを行うのは良いことです（上記の文字列の例のように）。
- そしてあなたが言うように;順序付け、集約、サブクエリ、結合などは常にDB側である必要があります。
- また、それらについては話していませんが、トリガーは通常、悪い/必要です。
ここで直面するいくつかの主要なトレードオフがあり、バランスは実際にはアプリケーションによって異なります。
いくつかのことは間違いなく-毎回-常にSQLで行われるべきです。多くのタスクのいくつかの例外（日付など）を除外すると、SQLは非常に扱いにくくなり、邪魔にならない場所にロジックが残る可能性があります。コードベースで特定の列への参照を検索する場合（たとえば）、それは ビューまたはストアドプロシージャに含まれているものを見逃しがちです。
パフォーマンスは常に考慮事項ですが、アプリや特定の例によっては、それほど大きなものではない場合があります。保守性とおそらく非常に有効であるというあなたの懸念と、私が言及したパフォーマンス上の利点のいくつかはごくわずかなので、時期尚早の最適化に注意してください。
また、他のシステムがDBに直接アクセスしている場合（たとえば、レポート、インポート/エクスポートなど）、DBにロジックを追加することでメリットが得られます。たとえば、別のデータソースからユーザーを直接インポートする場合は、電子メール検証関数のようなものがSQLに実装されています。
簡単な答え：状況によって異なります。 :)