デフォルトでは、オブジェクト (テーブル、ストアド プロシージャなど) は dbo 所有者/スキーマで設定されます (ms sql 2000 では所有者と呼ばれ、ms sql 2005 ではスキーマと呼ばれていると思います)。
所有者/スキーマは、実際にはデータベース内のロールまたはユーザーです。私は常にデフォルトの dbo のままにしてきましたが、最近、マイクロソフトのトレーニング ブックで、一部のテーブルとストアド プロシージャの所有者/スキーマが異なる例をいくつか見ました。これを行うのはいつ、またその理由は?
セキュリティ上の懸念がある場合、スキーマの使用は非常に有益です。
データベースにアクセスするアプリケーションが複数ある場合、ロジスティクス部門に人事レコードへのアクセス権を付与したくない場合があります。したがって、すべての人事表を hr スキーマに配置し、hr ロールのユーザーにのみアクセスを許可します。
6 か月後、ロジスティクスは内部経費勘定を知る必要があり、これらの青いペンのパレットすべてを正しい場所の担当者に送ることができます。次に、hr スキーマとロジスティクス スキーマを表示する権限を持つユーザーとして実行するストアド プロシージャを作成できます。ロジスティクスのユーザーは、HR で何が起こっているかを知る必要はありませんが、それでもデータを入手できます。
また、cfeduke が提案した方法でスキーマを使用し、それらを使用してオブジェクト ブラウザーで物事をグループ化することもできます。これを行っている場合は、本当に単一の dbo.Address が必要なときに Person.Address と Company.Address を作成することになる可能性があるため、注意してください (私はあなたの例、cfeduke をノックしているわけではなく、両方を説明するために使用しているだけです)アドレス テーブルは同じである場合もあれば、異なる場合もあり、その YMMV である場合もあります)。
私は過去に同様の名前空間でスキーマを使用していたので、Address ( [Person].[Address], [Company].[Address]) という名前のエンティティを複数持つことができました。これの利点は、SQL Management Studio での視覚的な編成です。すべてを 1 つのスキーマの下に置き、単一の識別子 (つまり ) でテーブルに名前を付けることで、同じことを得ることができます[dbo].[PersonAddress]。
また、すべての開発マシンで SQL Server Developer Edition を実行する前に、開発者対開発者の開発にもそれらを使用しました (私のキャリアの初期に集中開発データベースがあったとき)。
SQL 2000 では、スキーマはデータベース ユーザーに相当しますが、SQL 2005 では、各スキーマは、それを作成したデータベース ユーザーとは独立して存在する個別の名前空間です。
後で他のプロジェクトで使用される可能性のある機能やモジュールを作成する必要がある場合は、スキーマを使用します。これにより、モジュールで使用されるデータベース オブジェクトを分離できます。
組織
開発環境では、オブジェクトの実稼働コピーは dbo ですが、開発者は独自のスキーマで開発できます。その後、コードは製品コピーまたはその変更を非常に簡単に参照できます。エイリアスを使用すると、この手法をさらに簡単にすることができます。
また、本番データベースは多数のシステムまたはサブシステムをサポートする場合があります。個別のスキーマを使用して、これらのオブジェクトをグループ化しておくことができます。
この記事では、SQL Server 2000 から 2005 への変更点も含めて詳しく説明しています。