非dboスキーマと新しいデータベースをいつ使用するかの決定基準

私はほとんどがアプリケーション開発者ですが、現在のプロジェクト（MS SQL Server 2008の場合）のために、すべての事前データベース作業をしなければならないことに気付いています。最初の決定として、別のデータベースを使用して状態を分割するか、同じデータベース内の別のスキーマを使用するかを判断しようとしています。私はSQL Serverスキーマを少し読みましたが、オブジェクトドメイン（私は好きです）を分離する自然な方法のように思えますが、このパターンに隠れたコストがあるかどうかはわかりません。

これら2つのアプローチを選択する際に考慮すべき、より実用的なものは何ですか？dbo.mytableを支持しない場合、アーキテクチャにmyschema.mytable他の課題（または問題）を作成しますか？

補足として...ある時点で、これは実際の DBAに引き継がれ、保守/サポートされるので、私は彼らの生活を困難にしないように努めています。

まず、OOの意味でスキーマを名前空間またはオブジェクトドメインと見なさないでください。スキーマは、本質的に何らかの付加価値を持つ許可コンテナです（以下を参照）

また、「個別のスキーマ」または「個別のデータベース」は2つの異なる概念です。トランザクションおよび参照の一貫性が必要なデータは、同じデータベースに存在する必要があります。1つのデータベースまたは10を参照してください？詳細についてはブログ記事。

そのデータベースでは、オブジェクトを整理するためにスキーマを使用しても使用しなくてもかまいません。

個人的には、スキーマのファンであり、常に使用しますが、アクセス許可や論理的なグループ化などに使用します。そのために、一般的な意見が彼らに有利であることがわかる以前の質問を参照します。

• スキーマ設計-ベストプラクティス？
• テーブルとビューに名前を付けるとき、どの標準に従う必要がありますか？
• スキーマの過剰使用/正しい使用？

個別のデータベースの場合については、Aaronの回答を参照してください。ただし、これはすべて「トランザクションおよび参照の一貫性」要件に依存します。

@gbnに同意します。分離用のスキーマと分離用のデータベースを使用してソリューションを設計しましたが、データベースを使用する方がはるかに実用的であることがわかりました。いくつかの理由：

1. アプリをコンテキスト固有のデータベースに接続してから同じクエリを実行する方が<schema>、すべてのオブジェクト参照の前にクエリを挿入するよりもはるかに簡単です。これは、多くの動的SQL、デフォルトスキーマを使用したさまざまなアプリケーションログイン（コードがスキーマプレフィックスを使用せず、アプリケーションユーザーのデフォルトスキーマに依存しているため、プランキャッシュが膨大になり、デバッグが困難になる）に役立ちます。または管理する多数のストアドプロシージャ（スキーマごとに必要な場合は単純なレポートを想像してください。コードが変更されると、同じコードをスキーマごとに1回変更する必要があります）。
2. データベースで分離することで、1つの大きな包括的なデータベースからオブジェクトをリッピングすることなく、ビジーなデータベースをより高速または異なるストレージ/インスタンスに柔軟に移動できます。ほとんどの人はこれまで事前に考えていませんが、これは間違いなく潜在的な規模の問題です。特に、サーバー上のほとんどのリソースを「引き継いで」必要とする1つのスキーマが存在する場合、それらを既にスキーマで分離していても、それらを分割するのは非常に面倒な作業です。
3. また、個別のデータベースを使用すると、部門ごとに異なるメンテナンスおよびバックアップスケジュールを設定できます。「州による分割」が何を意味するのかわかりませんが、顧客を分離することを意味すると仮定すると、データ損失、インデックスメンテナンスなどの要件と許容範囲が異なる顧客がいる可能性があります。
4. 法律または企業ポリシーにより、お客様のデータを他の人から分離しておく必要がある顧客になってしまう可能性があります。通常、これはデータベースレベルで受け入れられますが、通常、スキーマレベルでは不十分です。これらの顧客は現在いないかもしれませんが、もしそうすれば、後で実際の問題になる可能性があります。