dboスキーマは避けるべきですか？
Dboスキーマに関しては：
- データベースオブジェクトを作成するときに、dboスキーマを使用しないことをお勧めしますか？
- なぜdboスキーマを避けるべきなのか、それともすべきなのか？
- どのデータベースユーザーがdboスキーマを所有する必要がありますか？
他のユーザーがデータベースを使用している場合に、スキーマを使用してそのユーザーのアクセスを制限できるようにする必要があるため、これは良い方法かもしれません。たとえば、データベースには次のテーブルがあります。
HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings
人事部長としてHRスキーマのすべてにアクセスでき、IT部長として従業員のユーザー名とアクセスレベルを確認できます。 Engineering部門は、どの求人サイトがアクティブであるかなどを確認できます。dboがすべてのテーブルの設定されたスキーマである場合、データをセグメント化してアクセスロールを提供するのが難しくなります。
SQL Serverのアイデアは、さまざまな部門がアクセスしてクエリを実行できる製品を提供することだと思います。実際には、DBA/DBDevのみが実際にデータベースにアクセスし、通常はアプリケーションデータのみを保存します。
また、読みやすさと管理のしやすさにも役立ちます。最初に赤面したのは、どのテーブルにどのデータが含まれていて、データがどのように分離されているかを簡単に識別できることです。
個人的には、一般的な方法としてスキーマを定義することを好みます。スキーマは計画に対してギリシャ語であることを忘れないでください。レイアウトされたスキーマ構造があると、データの計画と識別に役立ちます。
これを行う実際の技術的な理由はないので、これは本当にユーザーの好みによると思います。実際には、簡単にするために、セキュリティ要件で別段の定めがない限り、常にdboを使用すると言っています。もちろん、組織化の目的だけでいつでもそれを行うことができます。
どちらかといえば、dboはSQL Serverのデフォルトであるため、避ける必要があります。また、説明もありません。他のすべてのデフォルト名と同様に、ハッカーのライフをより簡単にすることがわかっているためです（ただし、スキーマ名を理解しようとしているだけの場合は、おそらくすでにボーキングされています）。
私が働いている場所では、スキーマを使用してデータベースを論理的なセクションに分割し、スキーマに権限を割り当てています。
たとえば、データベースを備えた在庫システムがあるとします。メインテーブルはinvスキーマにある可能性があります。データベースに何かをインポートする場合、ステージングスキーマがインポートプロセスの一部として使用されます。ユーザーがアクセスする必要のないシステムストアドプロシージャがある場合は、spスキーマに配置します。
スキーマはSQL 2005より前に隠されていたため、これまでのベストプラクティスではなく、すべてがdboスキーマに入れられていました。 SQL Serverチームはそれをベストプラクティスとして示し、それに関する記事を公開しました。 SQL Serverのベストプラクティス–データベースオブジェクトスキーマの実装
誰がスキーマを所有する必要があるかに関する他の質問：dboスキーマはdboユーザーアカウントが所有しています。