包含データベースには欠点がありますか？

SQL Server 2012は、データベースに必要なすべて（ほとんどすべて）がデータベース自体に含まれる「包含」データベースの概念を導入しました。これは、サーバー間でデータベースを移動するときに大きな利点を提供します。新しいデータベースを設計するとき、これが私のデフォルトの戦略であるかどうかを知りたいと思います。

MSDNには、包含データベースのいくつかの欠点がリストされており、大きな欠点は、変更の追跡とレプリケーションのサポートが不足していることです。他にありますか？これらの機能を使用しない場合、包含データベースを使用しない理由はありますか？

包含データベースの主な目的は、データベースを新しいサーバーに簡単に移植できるようにすることです。それを念頭に置いて、この移行をより困難にするいくつかの潜在的な問題を扱います-そして、ほとんどの場合、包含データベースがSQL Server 2012に部分的にしか含まれないという事実を中心に展開します（包含は実際には強制されません）。

接続文字列

包含データベースへの接続文字列は、接続文字列でデータベースを明示的に指定する必要があります。ログインのデフォルトデータベースに依存して接続を確立することはできなくなりました。データベースを指定しない場合、SQL Serverは含まれるすべてのデータベースをステップスルーし、資格情報が一致する可能性のあるデータベースを見つけようとしません。

クロスデータベースクエリ

同じサーバー上の2つの異なるデータベースに同じパスワードで同じユーザーを作成した場合でも、アプリケーションはデータベース間クエリを実行できません。ユーザー名とパスワードは同じかもしれませんが、同じユーザーではありません。その理由は？ホストされたサーバーにデータベースが含まれている場合、同じホストされたサーバーを使用している他の誰かと同じユーザーが含まれることを妨げないでください。完全な封じ込めが到着したとき（おそらくSQL Server 2012以降のバージョンで は）、とにかくデータベース間のクエリは絶対に禁止されます。含まれるデータベースユーザーと同じ名前のサーバーレベルのログインを作成しないことを強く、強く、強くお勧めします。また、含まれるデータベース間で同じ含まれるユーザー名を作成しないようにしてください。含まれている複数のデータベースにヒットするクエリを実行する必要がある場合は、適切な特権を持つサーバーレベルのログインを使用して実行します（これはsysadminであると思われるかもしれませんが、読み取り専用クエリの場合はでCONNECT ANY DATABASEありますSELECT ALL USER SECURABLES）。

同義語

ほとんどの3部と4部の名前は簡単に識別でき、DMVに表示されます。ただし、3部または4部の名前を指すシノニムを作成する場合、これらはDMVに表示されません。そのため、シノニムを多用すると、外部の依存関係が失われる可能性があり、データベースを別のサーバーに移行する時点で問題が発生する可能性があります。私はこの問題について不満を言いましたが、「設計」としてクローズされ、新しいフィードバックシステムへの移行に耐えられませんでした。DMVでは、動的SQLを介して構築される3部と4部の名前も見逃します。

パスワードポリシー

パスワードポリシーが設定されていないシステムに包含データベースユーザーを作成した場合、パスワードポリシーが設定されている別のシステムに同じユーザーを作成するのは難しいかもしれません。これは、CREATE USER構文がパスワードポリシーのバイパスをサポートしていないためです。この問題についてバグを報告しましたが、未解決のままです（また、Connectが廃止されたとき、この動きに耐えられませんでした）。そして、パスワードポリシーが設定されたシステムでは、ポリシーを簡単にバイパスするサーバーレベルのログインを作成できますが、そうするデータベースユーザーを作成することはできません-このユーザーは本質的にはセキュリティリスクが少ない。

照合

tempdbの照合に依存できなくなったため、明示的な照合を現在使用しているコードを変更するかDATABASE_DEFAULT、CATALOG_DEFAULT代わりに使用する必要がある場合があります。潜在的な問題については、このBOLの記事を参照してください。

IntelliSense

包含ユーザーとして包含データベースに接続する場合、SSMSはIntelliSenseを完全にサポートしません。構文エラーの基本的な下線が表示されますが、オートコンプリートリストやツールチップなどの楽しいものはありません。私はこの問題に関するバグを提出しましたが、それは未解決のままです -もう1つは移動に耐えられませんでした。

SQL Serverデータツール

データベース開発にSSDTの使用を計画している場合、現在は包含データベースの完全なサポートはありません。SSDTは現在、コンテインメントが何で、何が壊れる可能性があるかを知らないため、コンテインメントを破る機能または構文を使用しても、プロジェクトのビルドは失敗しません。

ALTER DATABASE

ALTER DATABASE含まれているデータベースのコンテキスト内からコマンドを実行する場合、rR ALTER DATABASE fooを使用する必要がありますALTER DATABASE CURRENT-これは、データベースを移動したり、名前を変更したりした場合に、これらのコマンドが外部コンテキストまたは参照について何も知る必要がないようにするためです。

他のいくつか

おそらくまだ使用すべきではないものの、サポートされていない、または非推奨であり、包含データベースで使用すべきでないもののリストに記載する必要があるもの：

• 番号付き手順
• 一時的な手続き
• バインドされたオブジェクトの照合順序の変更
• 変更データのキャプチャ
• 変更追跡
• 複製

つまり、これらは必ずしも包含データベースを使用することの不利な点ではなく、単に知っておくべき問題であり、すべて公式ドキュメントで明示的に開示されているわけではありません。

また、包含データベースが移行される場合、可用性グループの一部である場合、またはミラーリングされる場合、すべての潜在的な移行先サーバーのsp_configureオプションcontained database authenticationが1に設定されていることを確認する必要があります。

あなたは見つけることができ、このブログの記事有益なだけでなく、これを彼らはRTM-日前にもかかわらず、。

包含データベースの詳細を知りたい場合は、この記事を読むことをお勧めしますhttp://www.sqlshack.com/contained-databases-in-sql-server/

この記事では、包含データベースを使用する主な利点/欠点を特定しています。

欠点

部分的に含まれるデータベースは、照合の変更を伴う組み込み関数に依存するレプリケーション、変更データキャプチャ、変更追跡、スキーマバインドオブジェクトなどの機能を使用できません。

長所

一方、既に述べたように、次のような包含DBを使用する利点がいくつかあります。

• 
  孤立したユーザーの問題が発生しないため、データベースをあるサーバーから別のサーバーに移動するのは非常に簡単です。
• メタデータは包含データベースに保存されるため、より簡単で移植性が高くなります
• 含まれているDBユーザーに対してSQL ServerとWindowsの両方の認証を取得することは可能です

記事は以下にも役立ちます：

• 新しい包含データベースの作成（SQL Serverの[オプション]ページで包含タイプを[部分]に設定し、T-SQLクエリを使用してデータベースを作成する）
• SQL Server Management Studioを使用して包含D​​Bに接続する（接続パラメーターで包含DB名を指定する必要があります）
• 既存のデータベースを包含データベースに変換する
• 含まれているデータベースで作業し、含まれているユーザータイプのログインをすべてリストする

欠点の1つは、包含データベースユーザーがログイン（MUST_CHANGE）のように自分のパスワードを強制的に変更できないことです。ユーザーは、ユーザーに変更ユーザー権限を付与し、SQLステートメントを使用してパスワードの変更方法を指示しない限り、自分のパスワードを管理できません。ユーザーインターフェイスを介して管理するのが簡単な場所はどこにもありません。

追加の注意点として、「PIVOT」および「UNPIVOT」句に予期しないドキュメント化されていないメタデータの使用が見つかりました。これはシステムカタログのみ（sys.tables / sys.columns / etc）にあるべきだと思いました。msdnに記載されているとおり：

包含データベースでは、カタログ照合Latin1_General_100_CI_AS_WS_KS_SC。この照合は、SQL Serverのすべてのインスタンスに含まれるすべてのデータベースで同じであり、変更できません。

しかし、「PIVOT」および「UNPIVOT」句も実行メカニズムとしてシステムカタログを使用することは言及していません。そのため、移行中に "PIVOT"および "UNPIVOT"句を使用すると、どこでも照合競合エラーが発生します。ここにいくつかの再現があります：

/*step1 create a table belongs to a contained database and populate some data*/
create  table dbo.test1 (col1 varchar(100),col2 varchar(100))
insert  dbo.test1 values('a','x')
insert  dbo.test1 values('b','y')
insert  dbo.test1 values('c','z')

/*step2 lets see its collation you will see it is correctly as same as its (contained) database */
select name,collation_name from sys.columns where object_name(object_id) = 'test1'

/*step3 reproduce an unpivoted column*/
select * into dbo.test2
from (select * from dbo.test1) a unpivot (val for col in (col1,col2)) a


/*step4 lets check its collation you will see the column specified at "FOR" clause is created as Latin1_General_100_CI_AS_KS_WS_SC */
select name,collation_name from sys.columns where object_name(object_id) = 'test2'

/*step5 make use of the unpivoted table without awareness will cause an error*/
select val + ' = ' + col from dbo.test2 

/*step6 clean up*/
drop table dbo.test1
drop table dbo.test2

また、包含データベースに関する記事のほとんどが不完全であることがわかります。そのため、使用を決定するには、非常に優れた即興演奏が必要です。