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