在架构中有一些表而一些没有是不好的做法吗？答案

【问题标题】：Is it bad practice to have some tables within a schema and some not?在架构中有一些表而一些没有是不好的做法吗？
【发布时间】：2011-12-20 09:08:13
【问题描述】：

我最近开始在一家新公司开发一个 Web 应用程序，并开始进行一些更改，例如我所有的新代码都使用存储过程，而不是在后面的代码中使用查询字符串。

我最近与我的主管讨论了使用数据库模式来整理我们的数据库并使事情易于管理。我正在使用的应用程序是一个内部网 ASP.Net 站点，每个部门都有多个部分，我想为每个部门实现一个模式，以便清楚哪些过程/表属于应用程序的哪些部分。

我的问题是将新表/过程等添加到数据库架构中但保留其他所有内容然后慢慢地将现有表添加到架构中是否是不好的做法？还是我们应该一次性完成并将所有内容添加到架构中？

还有一些风险（性能或其他方面）让一些表在一个模式中，而另一些只是在数据库中，就像现在一样？

抱歉，这可能是一个相当简单的问题，但我不是 DBA，到目前为止一直在努力寻找任何答案。

谢谢

【问题讨论】：

【解决方案1】：

架构没有被广泛使用。你会发现一些数据库源代码控制和代码生成器不能很好地使用模式。甚至数据库本身也对模式感到不舒服，例如，如果存在安全不匹配的可能性（模式可以有自己的安全设置），它将拒绝缓存执行计划。

与触发器一样，最好完全避免使用模式。

【讨论】：

我不同意架构未广泛使用的评论。我看到他们使用得越来越多，而且我使用过的大多数工具都能很好地处理它们。模式是一种很好的安全机制，是为不同对象分配不同存储的另一种方法，等等。即使触发器仍然有它们的位置，我认为两者都不需要“完全避免”，但肯定不是模式 :-)

【解决方案2】：

我认为随手移动到模式的增量/重构方法是一种很好的方法。我没有看到任何性能问题。最大的问题是要记住开始对您的对象进行架构限定（即使在今天，您也应该这样做，因为它是性能的最佳实践）

SELECT columns 
FROM dbo.Table

而不是

SELECT columns
FROM Table

如果您符合您的架构限定条件，您应该没问题。如果您对此感到懒惰，最终将需要进行更多故障排除。

【讨论】：