我最近开始在新公司开发Web应用程序，并开始进行一些更改，例如我的所有新代码都使用存储过程，而不是在后面的代码中使用查询字符串。
我最近讨论过与我的主管一起使用数据库模式来整理我们的数据库并保持可管理性。我正在使用的应用程序是一个内部网ASP.Net站点，每个部门有多个部分，我想为每个部门实现一个模式，以便明确哪些过程/表属于应用程序的哪些部分。
我的问题是，将新的表/过程等添加到数据库模式中是不好的做法，但是保留其他所有内容然后慢慢地将现有表添加到模式中？或者我们应该一次性将所有内容添加到模式中吗？
还有任何风险（性能或其他方面）在模式中有一些表，有些只是在数据库中，就像现在一样吗？
很抱歉这可能是一个相当简单的问题，但我不是DBA，并且到目前为止一直在努力寻找任何答案。
由于
答案 0 :(得分：3)
我认为随时移动到模式的增量/重构方法是一种很好的方法。我认为没有性能问题。最大的问题是记住开始对你的对象进行模式限定（即使在今天你应该这样做，因为它是性能的最佳实践）
SELECT columns
FROM dbo.Table
而不是
SELECT columns
FROM Table
如果您符合您的架构资格，那么您应该没问题。如果你对它很懒，你最终会做更多的故障排除。
答案 1 :(得分：-1)
架构并未得到广泛使用。您将找到一些数据库源代码控制，代码生成器不能很好地与架构配合使用。即使数据库本身也对架构感到不舒服，例如，如果存在安全性不匹配的可能性，则会拒绝缓存执行计划（架构可以拥有自己的安全设置。）< / p>
与触发器一样，最好完全避免使用模式。