web-dev-qa-db-ja.com

SQL Server：sysテーブルではなくinformation_schemaテーブルを使用する必要がありますか？

SQL Serverには、メタデータ用の2つのスキーマがあります。

  • INFORMATION_SCHEMA
  • SYS

聞いたことがあるINFORMATION_SCHEMAテーブルはANSI標準に基づいています。例えば開発中ストアドプロシージャ。INFORMATION_SCHEMAテーブルがsysテーブルを超えていますか？

sqlsql-serversql-server-2008stored-proceduresmetadata
49
juur

私はいつもInformation_schemaは、sysスキーマを直接照会するビューです。

ビューはISOに準拠しているため、理論的には、さまざまなRDBMS間でクエリを簡単に移行できるはずです。

ただし、必要な情報がビューで利用できない場合があります。

ビューとSQL Serverカタログのクエリに関する詳細情報のリンクをいくつか提供しました。

http://msdn.Microsoft.com/en-us/library/ms186778.aspx

http://msdn.Microsoft.com/en-us/library/ms189082.aspx

31
codingbadger

事実がわかっているアプリケーションを作成する場合を除いて、移植可能である必要があるか、非常に基本的な情報だけが必要な場合を除き、私はデフォルトで独自のSQL Serverシステムビューを使用することから始めます。

Information_Schemaビューには、SQL-92標準と互換性のあるオブジェクトのみが表示されます。つまり、インデックスなどの非常に基本的な構成についても情報スキーマビューはありません（これらは標準で定義されておらず、実装の詳細として残されています）。SQLServer独自の機能は言うまでもありません。

さらに、移植性を想定できるのは、完全な万能薬ではありません。実装はまだシステム間で異なります。 Oracleは「そのまま」実装することはなく、 MySql docs と言います。

SQL Server 2000（これも標準に従う）のユーザーは、強い類似性に気付くでしょう。ただし、MySQLは、実装に関係のない多くの列を省略し、MySQL固有の列を追加しました。そのような列の1つは、INFORMATION_SCHEMA.TABLESテーブルのENGINE列です。

外部キー制約などのパンとバターのSQL構成要素の場合でも、Information_Schemaビューは、効率的なクエリを可能にするオブジェクトIDを公開しないため、sys.ビューよりも作業効率が大幅に低下します。

例えば質問 1秒から11分へのSQLクエリのスローダウン-理由？ と実行計画を参照してください。

INFORMATION_SCHEMA

Plan

sys

Plan

32
Martin Smith

INFORMATION_SCHEMAは、さまざまなデータベースとのインターフェースが必要になる可能性のある外部コードに適しています。 inデータベースのプログラミングを開始すると、ポータビリティのようなものがなくなります。ストアドプロシージャを作成している場合、それは特定のデータベースプラットフォームにコミットしたことを示しています（良くも悪くも）。 SQL Serverにコミットしている場合は、必ずsysビューを使用してください。

10
Peter Radocchia

他のいくつかの回答は繰り返さないが、パフォーマンスの観点を追加します。 Martin Smithが回答で述べているように、information_schemaビューは、複数の基礎となるソースから収集する必要がある標準列を公開する必要があるため、この情報の最も効率的なソースではありません。その観点から見ると、sysビューの方が効率的です。そのため、高いパフォーマンス要件があり、移植性について心配する必要がない場合は、おそらくsysビューを使用する必要があります。

たとえば、以下の最初のクエリはinformation_schema.tablesを使用してテーブルが存在するかどうかを確認します。 2つ目は、sys.tablesを使用して同じことを行います。

if exists (select * from information_schema.tables where table_schema = 'dbo' and table_name = 'MyTable')
    print '75% cost';

if exists (select * from sys.tables where object_id = object_id('dbo.MyTable'))
    print '25% cost';

これらのIO=を表示すると、最初のクエリにはsysschobjsおよびsysclsobjsへの4つの論理読み取りがあり、2番目のクエリには何もありません。最初のクエリには2つの非クラスター化インデックスシークとキーがあります。 2番目の検索は単一のクラスター化インデックスシークのみを実行しますが、最初の検索はクエリプランに従って2番目の検索より約3倍のコストがかかります。大規模なシステムでこれを何度も実行する必要がある場合、たとえば展開時間を増やすと、アップし、パフォーマンスの問題を引き起こします。ただし、これは実際には負荷の高いシステムにのみ適用されます。ほとんどのIT基幹業務システムには、このレベルのパフォーマンスの問題はありません。

繰り返しますが、これらの全体的なコストは、ほとんどのシステムの他のクエリと比較すると非常に小さいですが、システムにこのタイプのアクティビティが大量にある場合、合計する可能性があります。

1
Tombala