データベースでどのくらいの作業を行う必要がありますか? わかりました、データベースで正確にどれだけの「作業」を行う必要があるか、そして代わりにアプリケーションレベルでどれだけの作業を行う必要があるかについて、私は本当に混乱していますか?
つまり、データベース レベルではなくアプリケーション レベルで文字列を SHA2 ハッシュに変換する必要があるなど、明白なことについて話しているわけではありません。
しかし、「4列のデータを取得してアプリケーションレベルで大文字/連結を行うべきか、データベースレベルでこれらのことを行い、計算結果をアプリケーションレベル？
他にも例を挙げることができれば、それは素晴らしいことです。
それは本当にあなたが必要とするものに依存します.
私は自分のビジネス ロジックをデータベースで実行するのが好きですが、他の人はそれに対して宗教的に反対しています。
SQL でトリガーとストアド プロシージャ/関数を使用できます。
MySQL のリンク:
http://dev.mysql.com/doc/refman/5.5/en/triggers.html
http://www.mysqltutorial.org/introduction-to-sql-stored-procedures.aspx
http:// dev.mysql.com/doc/refman/5.5/en/stored-routines.html
トリガーとストアド プロセスでビジネス ロジックを実行する理由
データベース構造をビジネス ロジックに曲げることについて話しているのではなく、ビジネス ロジックをトリガーとストアド プロシージャに配置することについて話していることに注意してください。
これに強く反対する人もいますが、このアプローチは私にとってはうまく機能し、アプリケーションのデバッグとメンテナンスを大幅に簡素化しました。
Data一般に、データベースから" " のみを期待することをお勧めします。ビジネス/ドメインロジックを適用し、取得したデータを理解するためのアプリケーションまで。アプリケーション層で次のことを行うことを強くお勧めします。
1) 日付の書式設定 2) 補間/補外などの数学関数の適用 3) 動的ソート (列に基づく)
ただし、状況によっては、データベース レベルで実行する必要があることはほとんどありません。
私の経験では、多くのアプリケーションが単純な一連のテーブルから始まり、次にいくつかのストアド プロシージャを使用して基本的な機能を提供することがわかりました。これは非常にうまく機能します。通常、高いパフォーマンスが得られ、理解しやすいだけでなく、複雑な中間層の必要性も軽減されます。
ただし、アプリケーションは成長します。何千ものストアド プロシージャを持つ大規模なデータ ドリブン アプリケーションを目にすることは珍しくありません。トリガーをミックスに投入すると、元の開発者以外の誰にとっても (まだ開発中の場合)、維持するのが非常に難しいアプリケーションができあがります。
ほとんどのロジックをデータベースに配置するアプリケーションについて一言述べておきます。これらのアプリケーションは、優れたデータベース開発者がいる場合や、変更できないレガシー スキーマを使用している場合にうまく機能します。私がこれを言う理由は、ORM にスキーマを制御させると、アプリケーション開発のこの部分の苦労がほとんどなくなるからです (そうでない場合は、多くの場合、それを機能させるために多くの操作を行う必要があります)。
新しいアプリケーションを設計する場合、通常は、アプリケーション ドメイン (その設計はコードになります) によって決定されるスキーマを選択します。通常、ORM にオブジェクトとデータベース間のマッピングを処理させます。データ アクセスに関しては、ストアド プロシージャをルールの例外として扱います (レポートは、ORM を誘導して複雑な出力を効率的に生成しようとするよりも、sproc の方がはるかに簡単です)。
ただし、覚えておくべき最も重要なことは、設計に関しては「ベスト プラクティス」がないということです。設計のコンテキストで各オプションの長所と短所を比較検討するのは、開発者次第です。
私の意見では、アプリケーションはデータを使用し、データベースはそれらを提供する必要があり、懸念事項を明確に分離する必要があります。したがって、データベースは要求された条件に従ってソート、順序付け、フィルタリングされたレコードを提供しますが、そのレコードにビジネスロジックを適用し、ユーザーにとって意味のあるものに「変換」するのはアプリケーション次第です。
たとえば、私の前の会社では、作業時間計算のための大きなアプリケーションに取り組みました。この種のアプリケーションの明らかな機能の 1 つは、従業員の休暇日数を追跡することです。つまり、従業員の年間休暇日数、使用日数、休暇日数などです。基本的には、これらの列を自動的に更新するトリガーとプロシージャをいくつか作成できます。したがって、従業員が休暇日数を承認すると、申請した日数が「休暇プール」から取得され、「使用された休暇日数」に追加されます。かなり簡単なことですが、アプリケーションレベルで明示的にすることにしました。すぐに、その方法で満足しました。アプリケーションは労働法に準拠する必要があり、すべての従業員の休暇日が均等に計算されるわけではなく、休暇日がまったく休暇日ではない場合があることがすぐに判明しましたが、それは問題ではありません。この「簡単な」操作をデータベースに入れていたら、休暇関連のロジックを少し変更するたびにデータベースをバージョン管理する必要があり、アプリケーションしか更新できなかったという事実のために、顧客サポート分野で地獄に直行することになります。データベースを更新する必要はありません（もちろん、データベース構造が変更された明確な「ブレークスルー」の瞬間を除く）。