我正在创建一个没有遗留约束的全新数据库，因此我很好奇架构最佳实践是什么。
该数据库将被称为“SecurityData”。它存储有关债券的信息。
我已经确定的架构是:
- 导入 - 真正链接到其他数据库的服务器调用的 View 和过程
- 导出 - 供其他数据库使用的 View 和过程
- 暂存 - 用于批量插入的表，以便我们验证和清理数据。
- >？？？ - 包含有用数据的真实表格
- 历史记录 - 真实表的更改日志
问题:
- 我是不是要疯了，或者这有意义吗？
- 我应该将 dbo 用于我的“真实表”还是应该避免该模式，因为它往往会成为垃圾转储？
最佳答案
架构有双重用途:
- 安全容器。模式上的授予/拒绝/撤销适用于该模式中的所有对象。将相关的安全对象分离到 shcema 中可以轻松维护和控制访问。
- 命名空间。使用架构限定对象名称可以降低与其他应用程序甚至您自己的应用程序中的其他模块使用的名称发生冲突的可能性。
所以我问你的问题是:你为什么要首先使用模式？我并不是说你不应该这样做，但我想了解你最喜欢这些模式的哪些优点。如果您知道这个问题的答案，那么您就会知道您需要多少个模式以及这些模式是什么。当然，答案可以是我一开始给出的两个原因的混合，那是可以的。在这种情况下，您可能会发现从命名空间的角度来看有意义的事情从安全角度或角度来看却是一场灾难，反之亦然。
我自己就像您计划的那样使用了单独的模式，并且只是为了编程命名空间的好处。在开发过程中，它帮助我仅从对象的名称就可以了解它在应用程序中逻辑上属于哪个位置。
关于sql-server - SQL Server 2008 架构命名约定，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2211152/