在 SQL 2005 中使用模式的最佳实践？

Question

我们计划将 SQL 2000 数据库迁移到 SQL 2005，我熟悉 2005 年在各种所有者/模式下创建表或其他对象的能力。

我们在 SQL 2000 中并没有真正具备这种能力，所以我想知道创建/管理多个模式的指导方针/最佳实践是什么。

我应该为所有对象创建一个架构吗？ 我应该如何划分它们？

Answer 1

我尝试使用它来划分数据库内的责任区域。

我将有一个 util/utils/tools 模式，它在数据库之间非常可移植，并有一个数字表、UDF、SP 和帮助处理数据库的东西。这些过程不引用 utils 架构之外的任何内容。

然后我将有一个临时/工作/临时模式，我可以在其中执行 SELECT INTO 并创建我想要一个真实表而不是临时#table 的表。这里基本上只有表格，但表格上也可能有一些视图。

我有一个完全独立的数据库，用于验证导入和测试结果，但如果你没有，我可能有一个导入、导出和测试/测试结果架构，其中包含 ETL 或已知良好结果的内容进行回归测试。

那么其他一切都将只存在于几个模式中 - 或者可能只是一个。在大型系统中，每个子系统都可能是一个模式。其中的代码可以引用其他架构，但在引用架构之外的任何内容时都应该非常仔细地查看。

Answer 2

在设置新的测试服务器时，我对所有事情都使用一个巨大的模式，我只需要运行一个文件，我知道它包含所需的一切。

有些 ORM 会为每个对象生成一个文件，这可能有助于跟踪更改？但我没有看到手动执行此操作的目的。