5

私は sqlserver での CLR 統合の使用に関する記事を読み、潜在的な問題があればそれは何かと考えていました。私の考えは、レガシーデータベースの潜在的な不良データを検証するために使用していました。例として、電話番号列の人の名前があります。

編集: 問題はないと思いますが、それについて多くの議論が見られるものではなく、後で問題を引き起こす可能性のある缶ワームを開けないようにしたいと考えています. 私が尋ねる理由は、私がそれについて尋ねたとき、DBA が私を狂ったように見たからです。

4

4 に答える 4

6

SQL Server への CLR 統合自体は不安定ではありません。証拠として、SQL Server 2008 では、新しいgeography 型や geometry型など、多数のシステムデータ型が CLR データ型として実装されていたという事実を指摘します。そのため、CLR は、新しいコア機能をベースにするのに十分なほど安全であると見なされました。

そうは言っても、CLR は SQL プログラミングにまったく新しい武器をもたらし、自分自身を撃ちます。スレッドを開始したり、IPC 通信 (イベント、ミューテックス、セマフォ) をブロックしたり、外部に接続して I/O を待機したり、メモリで読み書きしたり、さまざまな Win32 API を呼び出したり、一般的に無謀な振る舞いをして大混乱を引き起こしたりすることができます。古い T-SQL プログラミングでは、同じことを達成するために、はるかに優れたハッキン​​グの才能が必要でした。

たとえば、フィールドの正規表現検証など、優れた制約のある動作を公開する新しいデータ型の実装を検討していますか? どうぞ。SQL がホストする CLR 内から Web サービス リクエストを行うことを考えていますか? あなたはそれを手に入れました、そしてあなたはあなたが得るすべてに値するでしょう！

経験則では、アセンブリが信頼できる要件 (EXTERNAL_ACCESS や UNSAFE なし) なしで読み込まれ、検証される場合は問題ありません。もちろん、SAFE アセンブリで while(1) {;} ループを記述することはできますが、T-SQL ストアド プロシージャを記述することもできます...

于 2009-07-09T18:40:21.227 に答える
2

1つの問題は、CLR（本番）assysをサーバーにどのように取得するかです。たとえば、当社には、SQLサーバーへのアクセスを許可せず、SSMSを介したリモート接続として提供するクライアントがいくつかあります。したがって、assydllをデプロイできるローカルパスはありません。解決策は、バイナリをバイナリblobまたは0x-hex文字列として一時テーブルにアップロードすることです。

次に、function /storedprocを更新するとどうなりますか？別のアセンブリに依存しているアセンブリを更新することはできません（関数のシグネチャが変更された場合のみであるかどうかは思い出せません）。アセンブリの新しいバージョンをアップロードする前に、常にすべてのsp / func/assysを削除すると思います。

ビルド/参照システムの統合はばかげています。sqlclrへの参照を追加するときは、そのdllをSQLSにデプロイする必要があります。VSは、そのdllをSQLSからそのプロジェクトの "obj / sqlclr"ディレクトリにコピーし、そこから使用します。次に、TFSビルドシステムを使用してそのプロジェクトをビルドする場合、ビルドを成功させるには、そのdllがそこにある必要があります。（共有SQLSサーバーに関連する回避策がありますが..）。

SQLSに本番dllがデプロイされている場合、VSは新しいdllのデプロイに失敗します。解決策は、本番dllを削除することです。

デバッガーをSQLCLRで動作させるのは簡単ではありません。ほとんどの場合、「sqladmin」（またはそのような）グループにドメインユーザー名（DOMAIN \ username）がないためにつまずきます。VS / SQLSが何が間違っているのか、なぜブレークポイントに到達できないのかを教えてくれるアドバイスはほとんどありません。

そうすれば、C＃を書いているときでさえ、ハードコードされた文字列でSQLを書くことになります。このでたらめを回避するためのヘルパーが存在するかどうかはわかりません。sqlclrにはnhibernate/sqlalchemyはありません。これは主に、多くの行などを処理する必要があるSPにあります。これによる機能への影響は少なくなります。

これは、BLレイヤーでnhibernateなどを使用すると、sqlclrレイヤーで再利用できなくなり、クラスが複製されることも意味します。SqlReaderからオブジェクトをインスタンス化することは、2009年には非常に、非常に、非常にうんざりしています。MSが考えていたのは、私を超えて、信じられないほどのがらくたです。

全体として、SQLCLRはT-SQLよりもはるかに優れていると思いますが、場合によっては、煩わしさが少ないため、T-SQLSPをコーディングするだけで済みます。

于 2009-07-09T19:08:24.070 に答える
2

私が見る主なもの：

  • データベース以外のもの、たとえば、レジ​​ストリの書き込み、サービスの停止/開始などを行うための UNSAFE 権限
  • SQL の記述を回避
  • 調整、追跡、微調整が困難

MS が SQL Server 2005 の CLR データ型として「日付」と「時刻」を実装しようとしたが失敗したという話があります... (2004 年のセミナーでの Itzak Ben-Gan)

于 2009-07-09T17:44:40.603 に答える
1

私が遭遇した問題の1つは、コンテキスト接続が理にかなった方法で動作しないことです(SOに関するリンクされた質問が提示するように)

それにもかかわらず、CLR は素晴らしいと思います。

于 2009-07-09T17:22:05.003 に答える