SQL Server 2008 架构命名约定

Question

我正在创建一个没有旧约束的全新数据库，所以我很好奇架构最佳实践是什么。

该数据库将被称为“SecurityData”。它存储有关债券的信息。

我已经确定的架构是：

• 导入 - 真正链接到其他数据库的服务器调用的视图和过程
• export - 供其他数据库使用的视图和过程
• staging - 用于批量插入的表，因此我们可以验证和清理数据。
• ？？？ - 包含有用数据的真实表格
• 历史记录 - 真实表的更改日志

问题：

1. 我的架构疯了还是有意义？
2. 我应该将 dbo 用于我的“真实表”还是应该避免使用该架构，因为它往往会变成垃圾转储？

Answer 1

架构有双重用途：

• 安全容器。架构上的授予/拒绝/撤销适用于架构中的所有对象。将相关的安全对象分离到一个 shcema 中，便于维护和访问控制。
• 命名空间。使用架构限定对象名称可以降低与其他应用程序甚至您自己应用程序中的其他模块使用的名称发生冲突的可能性。

所以我的问题是：为什么要首先使用模式？我并不是说您不应该这样做，但我想了解您最喜欢架构的哪个优势。如果您知道这个问题的答案，那么您就会知道需要多少个模式以及这些模式是什么。当然，答案可以是我在开始时给出的两个原因的混合，那是可以的。在这种情况下，您可能会发现从命名空间的角度来看有意义的是从安全角度或角度来看是一场灾难，反之亦然。

我自己就像您计划的那样使用了单独的模式，并且仅用于编程命名空间的好处。在开发过程中，它帮助我从一个对象的名称中看出它在应用程序中的逻辑归属。