dboスキーマは避けるべきですか？

dboスキーマに関しては：

• データベースオブジェクトを作成するときにdboスキーマを使用しないことはベストプラクティスですか？
• なぜdboスキーマを避けるべきなのですか？
• どのデータベースユーザーがdboスキーマを所有する必要がありますか？

データベースを使用している他のユーザーがいる場合、スキーマでのアクセスを制限できるようにするため、この方法をお勧めします。たとえば、データベースには次のテーブルがあります。

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

HRディレクターとして、HRスキーマ内のすべてにITアクセスできます。ディレクターとして、従業員のユーザー名とアクセスレベルを確認できます。Engineering部門は、DBOが、私は難しく、時間が私のデータをセグメント化し、アクセスロールを提供する必要がありますすべてのテーブルのセットスキーマだった場合など、ジョブサイトがアクティブであるかを見ることができます。

SQL Serverの考え方は、さまざまな部門からアクセスして照会できる製品を提供することだと思います。実際には、DBA / DBDevのみがデータベースに実際にアクセスし、通常はアプリケーションデータのみを保存します。

また、読みやすさと管理性にも役立ちます。最初は、どのテーブルがどのデータを保持し、どのようにデータが分離されているかを簡単に識別できます。

個人的には、スキーマを一般的な方法として定義することを好みます。スキーマは計画のためにギリシャ語であることを忘れないでください。スキーマ構造がレイアウトされていると、データの計画と識別に役立ちます。

これを行う技術的な理由はないので、これはユーザーの好みによるものだと思います。実際、簡単にするために、セキュリティ要件で別途定められていない限り、常にdboを使用します。もちろん、組織的な目的のためにいつでも行うことができます。

どちらかといえば、dboはSQL Serverのデフォルトであるため、避ける必要があります。また、dboはまったく説明的ではありません。他のすべてのデフォルト名と同様に、それが既知であるため、ハッカーの生活が非常に簡単になります（ただし、スキーマ名を把握しようとしているだけの場合は、すでに退屈している可能性があります）。

私が働いている場所では、スキーマを使用してデータベースを論理セクションに分割し、スキーマに権限を割り当てます。

たとえば、データベースを備えたインベントリシステムがあるとします。メインテーブルはinvスキーマにある場合があります。データベースに何かをインポートする場合、ステージングスキーマがインポートプロセスの一部として使用されます。ユーザーがアクセスする必要のないシステムストアドプロシージャがある場合、それらをspスキーマに入れます。

スキーマはSQL 2005より前に隠されていたため、以前はベストプラクティスではありませんでした。すべてがdboスキーマに入れられていました。SQL Serverチームはそれをベストプラクティスとして示し、それに関する記事を公開しました 。SQLServerベストプラクティス-データベースオブジェクトスキーマの実装

誰がそれを所有すべきかに関する他の質問に関しては、dboスキーマはdboユーザーアカウントによって所有されています。