スキーマの過剰使用/正しい使用？

尋ねたこれで質問をStackOverflowの、私は私が行っていることは正しいです/ベストプラクティスを疑問に思いました。

基本的に、私が作成するすべてのオブジェクトは、使用法を反映するスキーマ名を持つスキーマに入ります。たとえば、私にはスキーマAuditとAdmin（特に）があります。

これにより、にオブジェクトが残りませんdbo。これでいい？他に必要なことはありますか？

スキーマは優れたセキュリティツール（これを使用するのに十分な理由です）であるだけでなく、論理的な分離にも最適です。そして、これがあなたが実践していることのようです。

現在の要件で特別なセキュリティが必要ない場合でも、将来的には、監査に関連するすべてのデータベースオブジェクトがデータベースロールに対して安全である必要があると言います。これらのオブジェクトがdboスキーマ全体に散在している場合はdeny、個々のオブジェクトに対する権限を明示的に指定する必要があります。しかし、Auditスキーマを使用すると、単一の操作denyを実行するだけで済みます。

私は個人的にスキーマの使用を実践しています。データベースのすべてのものと同様に、幸せな媒体があります。データレイヤーの細かい側面ごとにスキーマを作成することはしません。スキーマが多すぎたり、分離されたりすることがあります。しかし、私はあなたがそれに近いところにいないと思います。

典型的なパターンは、権限に基づいてスキーマで、あなたが持っているだろうWebGUI、Desktopすべてのオブジェクトが同じpermissons持っているように、コードのためなどのスキーマからを。

明確なユーザーグループがある場合は、その権限を付与できますが、ある時点で権限が重複して乱雑になります。私はユーザー/グループのチェックを、権限オブジェクトではなくコード内のいくつかのチェックに任せる傾向があります。管理者とHR Excelユーザーがいるとします。これらはすべてDesktopコードを実行します。

データは通常共有されるので、Dataスキーマ、HistoryまたはまたはArchiveスキーマを持っています。

一部のコードはパブリックではない（UDFや内部プロシージャなど）のでHelper、クライアントコードで実行してはならないコードのスキーマを使用します。

最後に、StagingorやSystemorのようなスキーマMaintenanceは時々役立ちます。

dboスキーマにはユーザーオブジェクトはありませんが、ユーザーdboはすべてのスキーマを所有しています。

dboスキーマ内のオブジェクトはまったく問題ありません。スキーマの使いすぎでもないことがわかります。ただし、スキーマが多すぎるのはかなり主観的な質問です（ "OOデザインに必要なクラスの数は？"に相当します）。

私が言及する他の唯一のものは、個々のオブジェクトではなくスキーマに対するアクセス許可を付与することです（SOの質問では、アクセス許可について何も指定していません）。

スキーマを使用して、モジュールと使用パターンに従ってデータベースを分離したいと思います。データベーステーブルを理解するのが非常に簡単になるので、メンテナンスが簡単になります。私の最後のSQLサーバープロジェクトには、次のスキーマタイプがありました。LT-ルックアップテーブル

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

大きなモジュールの場合、それらをより多くのスキーマに分離しました。たとえば、personelモジュールは5つ以上のモジュールで構成されています。

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

他のアクティビティTEMP、MAINTANENCEのようなスキーマも含まれています。Management Studioでは、スキーマ名を使用してフィルタリングできます。MODULE1を担当する開発者は、名前でフィルタリングし、ほとんどの場合、これらのテーブルのみで作業します。これにより、開発者、データベース、新規参入者がデータベーステーブルを簡単に理解できるようになります。

sqlサーバーの場合とOracleの場合のベストプラクティスは異なる場合がありますが、私の経験では、スキーマが少ないほど優れています。
私は、特別な特権とメンテナンスを行うためのコードを備えたdba / programmerのスキーマが欲しいです。すべてのビジネスデータは1つのスキーマに格納する必要があるため、どこにあるかがわかります。命名規則は、テーブルまたはストアドコードの使用を区別するのに十分です。
複数のビジネスユニットがあり、それぞれが独自のスキーマを持つ重複がほとんどないさまざまなデータを使用しているケースを確認できます。それ以外の場合はシンプルにしてください。