SQLデータベース、特にSQL Serverを使用するのは初心者ではありません。ただし、私は主にSQL 2000の人であり、2005年以降は常にスキーマに戸惑っていました。はい、スキーマの基本的な定義は知っていますが、一般的なSQL Serverの展開で実際に何を使用していますか？
私はいつもデフォルトのスキーマを使ってきました。特殊なスキーマを作成する理由は何ですか？なぜ組み込みスキーマを割り当てるのですか？
編集：明確にするために、私はスキーマの利点を探していると思います。これをセキュリティスキームとしてのみ使用する場合は、データベースロールが既にその役割を果たしているようです。そして、それを名前空間指定子として使用することは、所有権（dbo対ユーザーなど）を使用して実行できるもののようでした。
私が得ているのは、所有者とロールでは実行できなかったスキーマの機能です。それらの具体的な利点は何ですか？
回答:
スキーマは、テーブル、プロシージャ、ビューを論理的にグループ化します。employeeスキーマ内のすべての従業員関連オブジェクトなど
また、1つのスキーマのみにアクセス許可を付与して、ユーザーがアクセスできるのはスキーマだけで、他には何も表示されないようにすることもできます。
C＃コードの名前空間と同じです。
MyDatabase.MySchemaスキーマのテーブルは、MyProject.MyDatabase.MySchema名前空間のエンティティクラスに魔法のようにマッピングされません。また.、テーブル名のドット表記（）によるハッキング_は、クラス名のアンダースコア（）として終了することにも注意してください。残念なことに、ただ食べ物。
また、プラグインデータの一種の名前衝突保護を提供することもできます。たとえば、SQL Server 2008の新しいChange Data Capture機能は、使用するテーブルを別のcdcスキーマに配置します。これにより、CDCテーブルとデータベースで使用されている実際のテーブルとの間の名前の競合を心配する必要がなくなり、実際のテーブルの名前を意図的に隠すことができます。
スキーマを個別にしておけば、特定のスキーマを新しいDBサーバーにデプロイすることでアプリケーションをスケーリングできます。（これは、明確な機能を持つのに十分な大きさのアプリケーションまたはシステムがあることを前提としています）。
例として、ロギングを実行するシステムを考えます。すべてのログテーブルとSPは[logging]スキーマにあります。システムの他の機能がロギングスキーマのオブジェクトと重複する（つまり、結合する）ことはまれですが、ロギングは良い例です。
この手法を使用するためのヒント-アプリケーション/システムのスキーマごとに異なる接続文字列を使用します。次に、スキーマ要素を新しいサーバーにデプロイし、スケーリングが必要なときに接続文字列を変更します。
私はこれについてブレントに同意する傾向があります...この議論をここで参照してください。http://www.brentozar.com/archive/2010/05/why-use-schemas/
要するに...スキーマは、非常に特殊なユースケースを除いて、それほど有用ではありません。物事が乱雑になります。あなたがそれを助けることができるならそれらを使わないでください。そして、K（eep）I（t）S（imple）S（tupid）ルールに従うようにしてください。
スキーマに関連付けられているユーザーをエイリアスで除外するメリットはわかりません。ここに理由があります...
ほとんどの人は最初にロールを介して自分のユーザーアカウントをデータベースに接続します。ユーザーをsysadminまたはデータベースロールdb_ownerのいずれかに任意の形式で割り当てるとすぐに、そのアカウントは「dbo」ユーザーアカウントにエイリアスされるか、完全なデータベースに対する権限。これが発生すると、デフォルトのスキーマ（ユーザーアカウントと同じ名前）以外のスキーマに自分を割り当てても、それらのdbo権限は、ユーザーとスキーマの下に作成したオブジェクトに割り当てられます。そのちょっと無意味な.....そして名前空間だけで、それらのオブジェクトの真の所有権を混乱させます。あなたが私に尋ねると、その貧弱なデザイン....誰がそれを設計したか。
彼らがすべきことは「グループ」を作成し、スキーマとロールを捨て、グループのグループを好きな組み合わせで階層化できるようにし、各階層で、アクセス許可が継承されているか、拒否されているか、カスタムで上書きされているかをシステムに通知するもの。これははるかに直感的であり、DBAはこれらのオブジェクトの実際の所有者をより適切に制御できます。現在のところ、ほとんどの場合、dboのデフォルトのSQL Serverユーザーには、ユーザーではなく、それらの権限があります。
私が長年働いていたORACLEショップでは、スキーマを使用して、さまざまなフロントエンドアプリケーションに適用されるプロシージャ（およびパッケージ）をカプセル化していました。ユースケース、ユーザー、およびシステム要件がまったく異なるため、アプリケーションごとに異なる「API」スキーマを使用することが理にかなっていることがよくあります。たとえば、1つの「API」スキーマは、開発/構成アプリケーションが開発者のみが使用するためのものでした。別の「API」スキーマは、ビューとプロシージャ（検索）を介してクライアントデータにアクセスするためのものでした。独自のデータベースを持つアプリケーションと開発/構成およびクライアントデータを同期するために使用された別の「API」スキーマカプセル化コード。これらの「API」スキーマの一部は、カバーの下では、依然として他の「共通」を介して共通の手順と機能を共有します
スキーマは非常に役立つものですが、スキーマがないことはおそらく世界の終わりではありません。本当に、SQL Serverにパッケージがないために本当に問題が生じますが、それは別のトピックです。
スキーマは多くの新機能のようなものだと思います（SQL Serverやその他のソフトウェアツールに関係なく）。開発キットに追加する利点が、設計と実装の単純さの損失を相殺するかどうかを慎重に評価する必要があります。
スキーマはオプションの名前空間とほぼ同じであるように見えます。オブジェクト名が衝突し、アクセス許可の細分性が十分でない状況にいる場合は、次のツールを使用してください。（最初に、より基本的なレベルで処理する必要のある設計上の問題があるかもしれないと言う傾向があります。）
問題がある可能性があります。それが存在する場合、一部の開発者は短期的な利益のために何気なくそれを使い始めるでしょう。そこに入るとクズになります。
SQL Server 2000では、作成されたオブジェクトはその特定のユーザーにリンクされました。たとえば、ユーザーがSamがEmployeesなどのオブジェクトを作成した場合、そのテーブルはSam.Employeesのようになります。サムが会社を去る場合、または他のビジネスエリアに移動する場合はどうでしょうか。ユーザーSamを削除するとすぐに、Sam.Employeesテーブルはどうなりますか？おそらく、最初に所有権をSam.Employeesからdbo.Employessに変更する必要があります。スキーマは、この問題を解決するソリューションを提供します。サムは、Emp_Schemaなどのスキーマ内にすべてのオブジェクトを作成できます。ここで、彼がEmp_Schema内にオブジェクトEmployeesを作成した場合、そのオブジェクトはEmp_Schema.Employeesと呼ばれます。ユーザーアカウントSamを削除する必要がある場合でも、スキーマは影響を受けません。
開発-開発者はそれぞれ、独自のスキーマをサンドボックスとして取得してプレイします。
ここでは、SQL Serverでスキーマを使用する良い実装例を示します。ms-accessアプリケーションがいくつかありました。それらをASP.NETアプリポータルに変換したいと考えました。すべてのms-accessアプリケーションは、そのポータルのアプリケーションとして作成されます。すべてのms-accessアプリケーションには、独自のデータベーステーブルがあります。それらのいくつかは関連しています。SQLServerの一般的なdboスキーマにそれらを配置します。残りは独自のスキーマを取得します。ASP.NETアプリポータルのAppに属しているテーブルを知りたい場合は、簡単にナビゲート、視覚化、および保守できます。