4

つまり、CLRストアドプロシージャにほとんどのビジネスロジックを実装することは、優れた設計ソリューションですか？

私は最近それらについて多くを読みましたが、それらがいつ使用されるべきか、ベストプラクティスは何であるか、それらが十分に良いかどうかを理解することができません。

たとえば、私のビジネスアプリケーションは

  • 大きな固定長のテキストファイルを解析し、
  • ファイルの各行からいくつかの数字を抽出し、
  • これらの数値によると、いくつかの複雑なビジネスルール（正規表現のマッチング、データベース内の多くのテーブルのデータに対するパターンマッチングなど）が適用されます。
  • この計算の結果として、データベースのレコードが更新されます。

ユーザーがファイルを選択したり、結果を表示したりするためのGUIもあります。

このアプリケーションは、データレイヤー、ロジックレイヤー、GUIレイヤーという従来の3層アーキテクチャを実装するのに適しているようです。

  • データレイヤーはデータベースにアクセスします
  • ロジックレイヤーはWCFサービスとして実行され、データレイヤーと対話してビジネスルールを実装します。
  • GUIレイヤーは、ロジックレイヤーとユーザー間の通信手段になります。

この設計を考えると、ほとんどのビジネスルールがSQL CLRに実装され、SQLServerに格納されていることがわかります。すべての生データをデータベースに保存し、そこで処理を実行して、結果を取得する場合があります。このソリューションにはいくつかの長所と短所があります。

長所：

  • ビジネスロジックはデータの近くで実行されるため、ネットワークトラフィックが少なくなります。
  • 並列処理と最適な実行プランを利用して、すべてのデータを一度に処理します。

短所：

  • ビジネスロジックの分散：一部はここにあり、一部はそこにあります。
  • 疑わしい設計ソリューションは、未知の問題に遭遇する可能性があります。
  • 処理タスクの進行状況インジケーターを実装するのは困難です。

SQLCLRについてのご意見をお聞かせください。誰かがそれを本番環境で使用していますか？そのようなデザインに何か問題はありますか？いいことですか？

4

3 に答える 3

4

私はそれをしません-CLRinsSQL Serverは多くのこと（ハッシュの計算、SQLが吸い込む文字列操作の実行、フィールド値を検証するための正規表現など）に最適ですが、複雑なロジックであるIMHOはデータベースでビジネスを行いません。

これはパフォーマンスの問題の1つのポイントであり、スケールアップするには非常にコストがかかります。さらに、すべてをそこに入れるか、または-まあ-メンテナンスに関して深刻な問題があります。

于 2010-05-20T15:03:58.417 に答える
2

一般に、パフォーマンスを大幅に向上させることができない場合、または技術的な理由がない限り、これを実行することはおそらく望ましくありません。このような理由の例としては、カスタム集計関数があります。

CLRストアドプロシージャを使用するいくつかの正当な理由：

  • カスタム集計関数など、テクノロジーの独自の機能を利用できます。

  • CLR Sprocからパフォーマンス上の利点を得ることができます。おそらく、早送りカーソルから読み取り、出力をコアにバッファリングし、それを宛先テーブルにバッチで一括ロードできる、レコードごとの高速処理タスクです。

  • .Netコードまたは.Netライブラリを少しラップして、データベースサーバーで実行されているSQLコードで使用できるようにします。この例として、OPの質問からの正規表現マッチャーがあります。

  • XPを使用せずにSQLコードからアクセスできるように、管理されていない、ひどく安全でないものをだましてラップしたいとします。技術的には、Microsoftは、XPは非推奨であり、多くのインストールではセキュリティ上の理由からXPが無効になっていると述べています。

    時々、クライアント側のコードを変更するオプションがないため（おそらく、既成のアプリケーションがある場合）、データベース内から外部アクションを開始する必要がある場合があります。この場合、トリガーまたはストアドプロシージャを外部と対話させる必要がある場合があります。たとえば、ワークフローのステータスをクエリしたり、ファイルシステムに何かを書き込んだり、（より極端に）画面を介してリモートメインフレームシステムにトランザクションを投稿したりします。スクレーパーライブラリ。

CLRストアドプロシージャを使用する悪い理由：

  • 通常は中間層で行われるもののパフォーマンスがわずかに向上します。ネットワーク接続を介して大量のデータをストリーミングしようとしない限り、ディスクトラフィックはネットワークトラフィックよりもはるかに遅い可能性があることに注意してください。

  • CLR sprocsはかっこいいので、CVに入れたい

  • セット指向のSQLを記述できません。

于 2010-05-20T15:18:20.010 に答える
2

個人的には、データベースに依存しないビジネス機能が必要です。高度なデータクエリが必要な場合にのみCLRストアドプロシージャを使用します（SQLで実行するのが簡単ではない形式を生成するため）。何をしているかにもよりますが、とにかく標準のストアドプロシージャを使用するとパフォーマンスが向上する傾向があるため、個人的には高度なタスクにのみ使用します。

私の2セント。

HTH。

于 2010-05-20T15:04:39.340 に答える