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