「SQLサーバーをうまく機能させるために、コードで何もしないでください」-これは悪い設計のレシピですか？

それは私が聞いたアイデアのほんの一握りの場所です。SQLで純粋に問題を解決しようとすると、特定のレベルの複雑さを超えると、コードで実際に処理する必要があることを多少認めます。

このアイデアの背後にあるロジックは、ほとんどの場合、データベースエンジンが、コードで実行できるよりもタスクを完了するための最も効率的な方法を見つけるのにより良い仕事をするということです。特に、データに対して実行される操作を条件として結果を作成する場合などです。おそらく現代のエンジンでは、クエリのコンパイルされたバージョンを効果的にJITしてキャッシュし、表面上は理にかなっています。

問題は、この方法でデータベースエンジンを活用することが本質的に悪い設計慣行であるかどうか（およびその理由）です。データベース内にすべてのロジックが存在し、ORMを介して単にヒットしている場合、行はさらにぼやけます。

素人の言葉で：

これらはSQLが行うように作られたものであり、信じられないかもしれませんが、私はコードで行われているのを見ました：

• 結合 -コード的に複雑な配列操作が必要になる
• データのフィルタリング（場所）-コード上、リスト内のアイテムの大量の挿入と削除が必要になる
• 列の選択 -コードに関しては、重いリストまたは配列の操作が必要です
• 集約関数 -コード的には、値と複雑なスイッチケースを保持するために配列が必要です
• 外部キーの整合性 -コード的には、挿入前にクエリが必要であり、アプリの外部でデータを使用する人はいないと想定しています
• 主キーの整合性 -コード的には、挿入前にクエリが必要であり、アプリの外部でデータを使用することはないと想定しています

SQLまたはRDBMSに依存する代わりにこれらのことを行うと、付加価値のない大量のコードを書くことになり、デバッグおよび保守するコードが増えます。そして、危険なことに、データベースはアプリケーションを介してのみアクセスされると想定しています。

私は「あなたのために何ができるか、SQL Serverのコードでは決してしないためにこれを言い換えるとなるだけでなく」。

文字列操作、正規表現の動作など、SQL Serverでは実行しません（SQL CLRを除く）。

上記は、結合、集合演算、クエリなどのことについて話す傾向があります。その背後にある意図は、多くの重い作業を（得意なことを）SQL Serverに委任し、IOの量を可能な限り減らすことです（したがって、SQLに結合を実行させ、WHERE句でフィルターダウンして、他のデータセットよりも小さいデータセット）。

コードでSQLサーバーをうまく機能させることは絶対にしないでください（強調は私のものです）

答えの鍵は、単に何かをするのではなく、SQLが何かをうまくやっているかを探す必要があるということです。SQLは驚くほど強力な言語です。組み込み関数と組み合わせて、潜在的に多くのことを行うことができます。ただし、SQLで何かを実行できるという事実は、実際にSQLで実行するための言い訳にはなりません。

決定を下すための具体的な基準は、返されるデータの量とラウンドトリップの数を調べることです。ラウンド数を増やすことなく、サーバーにタスクを出荷してデータ量を削減できる場合トリップ、タスクはサーバーに属します。データ量が同じままであるか、ラウンドトリップ数が同時に低下せずに増加する場合、タスクはコードに属します。

これらの例を考慮してください：

• 生年月日を保存し、ユーザーのグループの年齢を計算する必要があります。SQLサーバーに減算を行わせることも、コード内で減算を行うこともできます。往復回数は同じままで、返送されるデータの量は増えます。したがって、コードベースのソリューションが勝ちます
• 生年月日を保存し、20〜30歳のユーザーを見つける必要があります。すべてのユーザーをクライアントにロードし、減算を行って年齢を見つけ、フィルター処理を行いますが、ロジックはSQL Serverに送信します。追加の往復を必要とせずにデータ量を削減します。したがって、SQLベースのソリューションが優先されます。

要するに、「コードベースでデータベース固有の操作を実行しないでください」と言うのは正しいことです。データベースで対処する方が適切だからです。

set base操作の例を見てください。ご存知かもしれませんが、RDBMSは一般的なデータストレージおよび操作操作を処理するために構築されています。

さらに、データベースのプロジェクト選択が重要な役割を果たします。RDBMS（MS SQL、Oracleなど）を持つことは、RavenDBのようなNoSQLデータベースとは異なります。

原則として、DBにはアプリケーションよりも多くの情報があり、一般的なデータ操作をより効率的に実行できます。たとえば、データベースはインデックスを維持しますが、アプリケーションはその場で検索結果のインデックスを作成する必要があります。したがって、他のすべてが同じであれば、アプリケーションではなくデータベースに作業をプッシュすることにより、全体的なワークロードを減らすことができます。

ただし、製品の規模が拡大するにつれて、通常、データベースの規模を拡大するよりもアプリの規模を拡大する方が簡単になります。大規模なインストールでは、アプリケーションサーバーがデータベースサーバーの数を10対1以上上回ることは珍しくありません。多くの場合、既存のサーバーを新しいハードウェアに複製するだけで、アプリケーションサーバーを追加できます。一方、ほとんどの場合、新しいデータベースサーバーを追加することは劇的に困難です。

この時点で、マントラはデータベースを保護するようになります。データベースの結果をキャッシュするmemcachedか、アプリケーション側のログに更新をキューイングするか、データを一度取得してアプリで統計を計算することにより、データベースのワークロードを劇的に削減でき、さらに複雑で脆弱なDBクラスター構成。

データベースを本来の目的に使用しないのは、デザインが悪いと思います。良いデータを持つデータベースの外でルールが適用されたデータベースを見たことはありません。そして、私は何百ものデータベースを見てきました。

したがって、データベースで行う必要のあること：

• 監査（アプリケーションのみの監査では、データベースへのすべての変更が追跡されないため、価値がありません）。

• デフォルト値、外部キー制約、およびすべてのデータに常に適用する必要があるルールを含むデータの制約。すべてのデータが常にアプリケーションを介して変更または挿入されるわけではありません。特に、一度に1つのレコードを実行するのが実用的ではない大規模なデータセットの1回限りのデータ修正があります（ステータス1として誤ってマークされたこれらの100,000レコードを更新してくださいアプリケーションコードのバグが原因で2になるか、クライアントAからクライアントBにすべてのレコードを更新してください。これは、企業Bが企業Aを購入したためです。

• JOINSおよびwhere句フィルタリング（ネットワーク経由で送信されるレコードの数を減らすため）

「時期尚早の最適化は、コンピュータープログラミングのすべての悪の根源です（とにかく、とにかく）」- Donald Knuth

データベースはまさにそれです。アプリケーションのデータ層。その仕事は、要求されたデータをアプリケーションに提供し、与えられたデータを保存することです。アプリケーションは、実際にデータを処理するコードを置く場所です。表示、検証など。

（ETCフィルタリングの核心、ザラザラ、突出、グループ化タイトルラインの感情を見事、及び点に正確である一方べき症例の圧倒的な数のDBに委ねられる）、「ウェル」の定義は、であるかもしれません注文。SQL Serverが高レベルのパフォーマンスで実行できるタスクは多数ありますが、実演できるタスクはSQL Serverが分離された反復可能な方法で正しく動作することはほとんどありません。SQL Management Studioは優れたデータベースIDEです（特にTOADのように連携した他のオプションを考えると）が、それには限界があります。まず、それを使用して実行するほとんどすべて（または実行する手続きコード）下のDB）は、定義により「副作用」（プロセスのメモリ空間のドメイン外にある状態の変更）です。さらに、SQL Server内の手続き型コードは、たった今、最新のIDEとツールで、カバレッジメトリックとパス分析を使用してマネージコードが測定できる方法を測定することができます（したがって、この特定のifステートメントがテストXで検出されたことを実証できます、Y、およびZ、テストXは条件を真にしてその半分を実行するように設計されており、YとZは「else」を実行します 。次に、特定の開始状態でデータベースを設定し、何らかのアクションを介してデータベースプロシージャコードを実行し、期待される結果をアサートできるテストがあることを前提としています。

これはすべて、ほとんどのデータアクセスレイヤーが提供するソリューションよりもはるかに困難で複雑です。データ層（および、さらに言えば、DAL）が正しい入力を与えられたときにジョブの実行方法を知っていると仮定し、コードが正しい入力を提供することをテストします。SPやトリガーなどの手続き型コードをDBから除外し、代わりにアプリケーションコードでこれらのタイプのことを行うことにより、アプリケーションコードの実行がはるかに容易になります。

人々が気付いていないように思われることの1つは、コード品質への影響に関係なく、SQLサーバーですべての処理を行うことは必ずしも良いことではないということです。

たとえば、いくつかのデータを取得して、そのデータから何かを計算し、そのデータをデータベースに保存する必要がある場合。次の2つの選択肢があります。

• データをアプリケーションに取り込み、アプリケーション内で計算してから、データベースにデータを送り返します
• ストアドプロシージャなどを作成して、データを取得し、データ全体を計算してから、SQLサーバーへの1回の呼び出しですべてを保存します。

2番目のソリューションは常に最速だと思うかもしれませんが、これは間違いです。SQLが問題（つまり、正規表現と文字列操作）に合わない場合でも無視します。データベースに強力な言語を持っているSQL CLRなどを持っているふりをしましょう。往復してデータを取得するのに1秒かかり、データを保存するのに1秒かかり、それをまたいで計算を行うのに10秒かかる場合。すべてをデータベースで実行している場合、それは間違っています。

確かに、あなたは2秒を剃ります。ただし、データベースサーバーの（少なくとも）1つのCPUコアの100％を10秒間浪費するのではなく、Webサーバーでその時間を浪費しませんでしたか？

Webサーバーは簡単にスケールアップできますが、一方でデータベース、特にSQLデータベースは非常に高価です。ほとんどの場合、Webサーバーも「ステートレス」であり、ロードバランサー以外の構成を追加することなく、思いのままに追加および削除できます。

そのため、操作から2秒を短縮するだけでなく、スケーラビリティについても考えてください。パフォーマンスへの影響が比較的小さく、はるかに安価なWebサーバーリソースを使用できるのに、データベースサーバーリソースなどの高価なリソースを無駄にする理由

SQLはデータ自体のみを処理する必要があるため、私はそれを見るのが好きです。クエリの外観を決定するビジネスルールは、コード内で発生する可能性があります。情報の正規表現または検証は、コードで行う必要があります。テーブルを結合したり、データをクエリしたり、クリーンなデータを挿入したりするためだけに、SQLを残す必要があります。

SQLに渡されるのはクリーンなデータである必要があり、SQLは、保存、更新、削除、または何かを取得するために必要なこと以上のことを実際に知る必要はありません。データをビジネスと考えているため、多くの開発者がSQLでビジネスロジックとコーディングをスローしたいと思っているのを見てきました。データからロジックを切り離すと、コードがよりクリーンで管理しやすくなります。

ただ私の0.02ドル。

一般に、コードがビジネスロジックを制御し、DBがロジックフリーハッシュであることに同意します。しかし、ここにいくつかの反論点があります：

主キー、外部キー、および必須（null以外）の制約は、コードによって適用できます。制約はビジネスロジックです。コードが実行できることを複製するため、データベースから除外する必要がありますか？

管理外の他の関係者はデータベースに触れていますか？もしそうなら、データの近くに制約を強制するのは良いことです。ロジックを実装するWebサービスにアクセスを制限できますが、これは「最初に」そこにいて、他のパーティでサービスの使用を強制する権限があることを前提としています。

ORMはオブジェクトごとに個別の挿入/更新を実行しますか？「はい」の場合、大規模なデータセットをバッチ処理するときに、深刻なパフォーマンスの問題が発生します。集合演算が進むべき道です。ORMでは、操作を実行できる可能性のあるすべての結合セットを正確にモデル化するのに苦労します。

「レイヤー」はサーバーによる物理的な分割、または論理的な分割とみなされますか？論理的には、どのサーバーでもロジックを実行することは、理論的にはそのサーバーの論理層に該当します。サーバーを排他的に分割するのではなく、異なるDLLにコンパイルすることにより、分割を整理できます。これにより、懸念の分離を維持しながら、応答時間を劇的に増加させることができます（ただし、スループットは犠牲になります）。スプリットDLLは、新しいビルドなしで後で他のサーバーに移動して、スループットを向上させることができます（応答時間を犠牲にして）。

イディオムは、ビジネスルールを維持すること、データを処理すること、リレーション（データと構造とリレーションシップ）を処理することです。それはすべての問題に対するワンストップショップではありませんが、手動のようなことを避けるのに役立ちますこれらがデータベースレベルで利用可能な場合、レコードカウンターの保守、関係の整合性の手動保守など。そのため、誰か他の人が来てプログラムを拡張したり、データベースと対話する別のプログラムを書いたりした場合、以前のコードからデータベースの整合性を維持する方法を理解する必要はありません。手動で保持されるレコードカウンターの場合は、他の誰かが新しいデータベースを作成して同じデータベースとやり取りする場合に特に関係します。新しく作成されたプログラムにカウンターの正確なコードがある場合でも、元のプログラムとほぼ同時に実行されている新しいプログラムが破損する可能性があります。可能であれば、挿入または更新ステートメントですぐに達成できる場合、新しいコードまたは更新されたレコードを書き込む前に（コードまたは個別のクエリとして）レコードを取得し、条件をチェックするコードもあります。データ破損が再び発生する可能性があります。データベースエンジンは原子性を保証します。条件付きの更新クエリまたは挿入クエリは、条件を満たすレコードのみに影響することが保証されており、更新の途中で外部クエリがデータを変更することはできません。データベースエンジンがより適切に機能する場合にコードが使用される状況は他にも多くあります。パフォーマンスではなく、データの整合性がすべてです。s可能であれば、挿入または更新ステートメントですぐに達成できる場合は、新しいコードまたは更新されたレコードを（コードで、または個別のクエリとして）書き込む前に、レコードを取得して条件をチェックするコードもあります。データ破損が再び発生する可能性があります。データベースエンジンは原子性を保証します。条件付きの更新クエリまたは挿入クエリは、条件を満たすレコードのみに影響することが保証されており、更新の途中で外部クエリがデータを変更することはできません。データベースエンジンがより適切に機能する場合にコードが使用される状況は他にも多くあります。パフォーマンスではなく、データの整合性がすべてです。s可能であれば、挿入または更新ステートメントですぐに達成できる場合は、新しいコードまたは更新されたレコードを（コードで、または個別のクエリとして）書き込む前に、レコードを取得して条件をチェックするコードもあります。データ破損が再び発生する可能性があります。データベースエンジンは原子性を保証します。条件付きの更新クエリまたは挿入クエリは、条件を満たすレコードのみに影響することが保証されており、更新の途中で外部クエリがデータを変更することはできません。データベースエンジンがより適切に機能する場合にコードが使用される状況は他にも多くあります。パフォーマンスではなく、データの整合性がすべてです。データベースエンジンは原子性を保証します。条件付きの更新クエリまたは挿入クエリは、条件を満たすレコードのみに影響することが保証されており、更新の途中で外部クエリがデータを変更することはできません。データベースエンジンがより適切に機能する場合にコードが使用される状況は他にも多くあります。パフォーマンスではなく、データの整合性がすべてです。データベースエンジンは原子性を保証します。条件付きの更新クエリまたは挿入クエリは、条件を満たすレコードのみに影響することが保証されており、更新の途中で外部クエリがデータを変更することはできません。データベースエンジンがより適切に機能する場合にコードが使用される状況は他にも多くあります。パフォーマンスではなく、データの整合性がすべてです。

したがって、実際には良いデザインのイディオムまたは経験則です。破損したデータがあるシステムでは、パフォーマンスの向上は役に立たないでしょう。

前述のように、ラウンドトリップは時間的に非常にコストがかかるため、目標はデータベースとの送受信をできるだけ少なくすることです。特により複雑なクエリでは、SQLステートメントを何度も送信することは時間の無駄です。

データベースでストアドプロシージャを使用すると、開発者はAPIのようにデータベースを操作できます。背後の複雑なスキーマを心配する必要はありません。また、名前といくつかのパラメーターのみが送信されるため、サーバーに送信されるデータも削減されます。このシナリオでは、ほとんどのビジネスロジックはコード内に存在できますが、SQLの形式ではありません。コードは、基本的に、データベースから送信または要求されるものを準備します。

覚えておくべきことがいくつかあります。

• リレーショナルデータベースは、外部キーを通じて参照整合性を確保する必要があります
• 1つのデータベースのスケーリングは難しく、費用がかかる場合があります。Webサーバーを追加するだけで、Webサーバーのスケーリングが非常に簡単になります。より多くのSQLサーバーのパワーを追加してみてください。
• C＃とLINQを使用すると、コードを介して「結合」やその他の操作を実行できるため、多くの場合、両方の長所を最大限に活用できます。

「時期尚早の最適化はすべての悪の根源です」-ドナルド・クヌース

ジョブに最適なツールを使用してください。データの整合性のために、これは多くの場合データベースです。高度なビジネスルールの場合、これはJBoss Droolsのようなルールベースのシステムです。データの視覚化の場合、これはレポートフレームワークになります。等

パフォーマンスに問題がある場合は、その後、データをキャッシュできるかどうか、またはデータベースへの実装が高速になるかどうかを確認する必要があります。一般に、追加のサーバーまたは追加のクラウドパワーを購入するコストは、追加のメンテナンスコストと追加のバグの影響よりもはるかに低くなります。