SQL 2000 データベースを SQL 2005 に移行する予定です。私は、2005 でさまざまな所有者/スキーマの下にテーブルやその他のオブジェクトを作成できることをよく知っています。
SQL 2000 ではそのような機能は実際にはありませんでした。そのため、複数のスキーマを作成/管理するためのガイドライン/ベスト プラクティスはどのようなものになるのだろうかと考えています。
すべてのオブジェクトに対して 1 つのスキーマを作成する必要がありますか? それらをどのように分割すればよいですか？
データベース内の責任範囲を分割するために使用しようとしています。
データベース間で移植性が高く、Numbers テーブル、UDF、SP、およびデータベースでの作業に役立つものを含む util/utils/tools スキーマを作成します。プロシージャは、utils スキーマ以外のものを参照しません。
次に、SELECT INTO を実行できるスクラッチ/ワーク/一時スキーマを作成し、一時テーブルではなく実際のテーブルが必要な場所にテーブルを作成します。ここには基本的にテーブルだけがありますが、テーブルのいくつかのビューも可能です。
インポートとテスト結果を検証するための完全に別のデータベースがありますが、それがない場合は、インポート、エクスポート、およびテスト/テスト結果のスキーマがあり、ETL または回帰テストの既知の良好な結果が含まれている可能性があります。に対して。
その場合、他のすべてはいくつかのスキーマにのみ含まれます。または、1 つだけになることもあります。大規模なシステムでは、各サブシステムがスキーマである場合があります。これらのコードは他のスキーマを参照できますが、スキーマ外のものを参照するときはいつでもかなり注意深く調べる必要があります。
新しいテスト サーバーをセットアップするときは、必要なものがすべて含まれていることがわかっている 1 つのファイルを実行するだけです。
一部の ORM はオブジェクトごとに 1 つのファイルを生成し、おそらく変更の追跡に役立ちますか? しかし、それを手動で行う目的がわかりません。