2016-09-13 1 views
0

地域のレポートデータを提供する必要がある新しいサービスに取り組んでいます。各領域には独自のdbテーブルがあり、各dbテーブルにはReportDateのような同じ名前の列がいくつかあります。異なるテーブルには、異なる/ユニークな列がたくさんあるため、各地域ごとに別々のテーブルを作成しています。約10の地域表があります。動的SQLのパフォーマンスと実装は?

私はsprocにダイナミックSQLを使用することを検討していますので、簡単なクエリを作成してから、各テーブルに対して一般的に実行することができます。これにより、すべてのテーブルに対して同じSQLを実行する10個の別々のクエリを作成して維持するのがはるかに迅速かつ簡単になります。

SSはこのタイプの実装を処理するのにかなり最適化されていますか?潜在的なパフォーマンスの問題がありますか?このインプリメンテーションのパフォーマンスを最適化するために必要な具体的な手順はありますか?誰かがここにダイナミックSQLは、1つの理由または別の "悪"だと思いますか?私は特に、ダイナミックSQLステートメントで渡す外部アプリケーションとは対照的に、SS内で完全に行われたダイナミックSQLを指しています。

答えて

0

これは短いコメントです。

動的SQLは非常に合理的な解決策です。実際には、プロシージャの最初の実行時にSQL文が最適化されるときに発生するパフォーマンス上の問題を防ぐことができます。これにより、他のパラメータに対して最適ではない実行計画が得られる可能性があります。

あなたが望むSQLを正確に生成することをお勧めします。追加のオーバーヘッドは、文をコンパイルするためのものです。複雑なクエリを実行していると仮定すると、クエリの実行にはコンパイルするよりもはるかに時間がかかるはずです。

動的SQLが悪いのは、それは意見の問題だと思います。私は長年にわたって複数のプロジェクトで非常に効果的に使用してきました。

0

SQL Serverには動的SQLに問題はなく、問題は開発者と正反対です。 Dynamic SQLは非常に便利で強力ですが、長期的な成功を収めるためには理解する必要のあるニュアンスがたくさんあります。通常、あなたが求めている基本的な質問の種類を尋ねる人は、落とし穴をナビゲートするための背景の深い人ではありません。

私にとって本当に目立つものは、地域が非常に異なり、完全に異なるデータベースに置く必要があるが、それらのすべてで同じストアドプロシージャを使用することを前提としています。それは私にとって意味をなさない、私はあなたが混乱に向かっていることを恐れている。

+0

各領域ごとに異なる表が怖いです。このクエリを考えてみましょう。地域(すべての地域ですべての売上)からSUM(売上)を選択します。すべての地域が1つのテーブルにない場合は、基本的なレポートとGUIユーティリティを実行するのは難しいです。 –

1

Dynamic SqlがAngel Not Evil !!!になっています。

10年前、リレーショナルデータベースには2つのルールしかありませんでした。 "常にストアドプロシージャを使用する"と "動的SQL(アドホッククエリ)を構築しない"という2つのルールがありました。

しかし、ゲームはORMの革命とSQLサーバー2005からSQLサーバー2016リリースまでの新しい世代のSQLサーバーによって変わりました。

Don’t Fear Dynamic SQL. When done correctly, it can be used effectively

動的SQLは確かにいくつかの欠点があります。

それは次のようなアドバイスを聞くために驚くべきではありません。しかし、適切に使用されると、パフォーマンスを向上させる機能を含む多くの肯定的な属性があります。動的SQLの高いパフォーマンスのための

条件:

  • 実行動的SQL sp_executesqlのないEXECを使用。条件(値を連結しないでください)

はsp_executesqlを、よりパフォーマンスを得るためにキャッシュされたプランを使用する場所のための

  • 使用パラメータ。

    ADO.NETはクライアントでsp_executeSQLというクエリを送信します。生成されたSQLはSQLプロファイラで表示できます。

    ORMは、動的SQLとしてCRUDを動的に生成し、データをオブジェクトにマップして、優れたパフォーマンスで開発をスピードアップします。

    SQL Serverにはsp_executesqlがあります。このストアドプロシージャは、パラメータマーカと引数の可変数のSQL文字列を使用するシステムストアドプロシージャです。

    クライアントは、パラメータ化された文を実行する必要があるときはいつでも、sp_executesqlに対するRPC要求を発行します。

    パラメータ化されたsp_executesqlコールは、再利用可能なキャッシュ・プランを持つ可能性が高くなります。

    ストアドプロシージャは、パラメータ置換を有する動的SQLの内容は2005年

    SQLサーバから起動(更新/挿入/削除)もADO.NETで生成された動的SQLのようにクエリを実行するための標準的な手順になっsp_executesqlをsp_executesqlを呼び出したバッチの実行計画とは別の実行計画としてコンパイルされて実行されます。 sp_executesqlをMSDN からsp_executesql

    抜粋文にパラメータ値の変化が唯一の変化であるときのTransact-SQLステートメントを何度も実行するストアドプロシージャの代わりに使用することができます。 Transact-SQLステートメント自体は定数のままで、パラメータ値のみが変更されるため、SQL Serverクエリオプティマイザは最初に実行するために生成された実行プランを再利用する可能性があります。

    動的SQLは次のように実行されます。 EXECUTE sp_executesql @SQLString、@ParmDefinition、@SalesID = @IntVariable;

    ダイナミックSQLを生成してパフォーマンスの良いユーザーは誰ですか? ADOで

    var ID=1; 
        string commandText = "select * from products WHERE productid = @ID;"; 
    

    :クライアントで

    は、我々は、クエリを実行した場合。NET:

    生成されたクエリは次のとおりです。

    exec sp_executesql N'select * from products WHERE productid = @ID;',N'@ID int',@ID=11 
    

    Dapperの(高性能ORM)

    Dapperのは、マイクロORM .NET用を開発し、スタックオーバーフローのチームが使用、焦点を合わせています生のパフォーマンスを第一の目的としています。

    生成されたクエリは、次のとおり

    exec sp_executesql N'select * from products WHERE productid = @ID;',N'@ID int',@ID=12 
    

    EntityFramework EF 6.3

    クエリ:

    exec sp_executesql N'SELECT TOP (1) 
        [Extent1].[ProductID] AS [ProductID], 
        [Extent1].[ProductName] AS [ProductName], 
        [Extent1].[SupplierID] AS [SupplierID], 
        [Extent1].[CategoryID] AS [CategoryID], 
        [Extent1].[QuantityPerUnit] AS [QuantityPerUnit], 
        [Extent1].[UnitPrice] AS [UnitPrice], 
        [Extent1].[UnitsInStock] AS [UnitsInStock], 
        [Extent1].[UnitsOnOrder] AS [UnitsOnOrder], 
        [Extent1].[ReorderLevel] AS [ReorderLevel], 
        [Extent1].[Discontinued] AS [Discontinued] 
        FROM [dbo].[Products] AS [Extent1] 
        WHERE [Extent1].[ProductID] = @p__linq__0',N'@p__linq__0 int',@p__linq__0=1 
    

    var id=1; 
    Product p = db.Products.FirstOrDefault(t => t.ProductID == id); 
    

    動的SQLを生成します

    などのツールでは、動的SQLを高性能で使用しています。

    結論: 動的SQLは、それがパラメータだ場合、良好なパフォーマンスで使用すると、リレーショナルDBで-同じではありません似た - しかし、オブジェクトを格納するのに問題は非常に一般的ですsp_executesqlを

  • 0

    で実行することができます1。 normalize +継承を検索するか、またはhereを参照してください。私は別のテーブルで同じ列を再作成することを避けるでしょう。あなたは問題を発見し始めました。また、条件付きロジックをSQLに入れるという方向に向かっています。私はそこに行かないだろう。

    動的SQLは問題ありません。文字列リテラルのSQL です。必要に応じてSQLをストアドプロシージャに入れてください。しかし私の場合、SQLリクエストはアプリケーションに属しているため、パッケージ化してアプリケーションにバージョン管理する必要があります。 QueryFirstは、アプリケーションにコンパイルする際にSQLの整合性を保つのに役立ちます。

    関連する問題