スキーマdbo
のすべてを含む既存のデータベースがあります。スキーマfoo
を使用して追加するオブジェクトを含むSSDTプロジェクトがあります
プロジェクトに次のようなテーブルがあります。
CREATE table foo.a (
id INT NOT NULL
CONSTRAINT [PK_foo_a] PRIMARY KEY CLUSTERED
CONSTRAINT [FK_foo_a] FOREIGN KEY REFERENCES [dbo].[a],
desc NVARCHAR(50) NOT NULL
)
Dbo.aに依存します。 dbo.aには、他の列への外部キーである多くの列があります。他の誰か(デフォルトのスキーマを維持している人)がdbo.aを変更する可能性があります。
私はdbo.aを次のように単純に保存したいと思います:
CREATE table dbo.a (
id INT NOT NULL
CONSTRAINT [PK_a] PRIMARY KEY CLUSTERED
)
したがって、内部的にビルドされますが、デプロイされません。それは可能ですか?
AgileSqlClub SqlPackage Deployment Filterを使用できます。
元の記事 から Ed Elliott によって複製された簡単な説明:
DLL
を_sqlpackage.exe
_と同じフォルダに配置します次のコマンドラインパラメータをデプロイメントに追加します。
_/p:AdditionalDeploymentContributors=AgileSqlClub.DeploymentFilterContributor
_ /p:AdditionalDeploymentContributorArguments="SqlPackageFilter=IgnoreSchema(BLAH)"
これにより、BLAH
スキーマの展開、削除、変更は行われません。
詳細については 元の記事 を参照してください。
SSDT
を使用してデータベースの一部のみを管理することは困難です。依存関係がない場合は、オブジェクトの削除を拒否して、プロジェクトに含めないようにすることができます。依存関係はありますが、それらを管理したくないので、システムをだます必要があると思います。
一つの方法が思い浮かびます。私はそれらを現在テストする能力がなく、これに「類似した」方法のみを使用しました。これは正確ではありません。
オプション#1:
_dbo.a
_を含む新しいデータベースプロジェクトを作成します。
3部構成の名前でテーブルを参照します。名前の最初の部分には、SQLCMD変数を使用します。例えば。 [$(DatabaseName)].dbo.a.
foo
データベースをデプロイしないでください。
パブリッシュファイルまたはCLIインターフェースを介して、$(DatabaseName)
を実際のデータベースと同じ名前にします。
これを行う「クリーンな」組み込みの方法(2016年現在)は、保存されたスキーマ比較ファイルを使用することです。あなたはできる: