在模式中包含一些表而另一些表不存在是一种不好的做法吗？
我最近开始在一家新公司开发 Web 应用程序，并开始进行一些更改，例如我所有的新代码都使用存储过程，而不是在后面的代码中使用查询字符串。
我最近与我的主管讨论了使用数据库模式来整理我们的数据库并使事情易于管理。我正在使用的应用程序是一个 Intranet ASP.Net 站点，每个部门都有多个部分，我想为每个部门实现一个架构，以便清楚哪些过程/表属于应用程序的哪些部分。
我的问题是，将新表/过程等添加到数据库模式中，但保留其他所有内容，然后慢慢将现有表添加到模式中，这是否是一种不好的做法？或者我们应该一次性将所有内容添加到模式中？
另外，像现在这样，将一些表放在模式中而将一些表放在数据库中是否存在任何风险（性能或其他）？
抱歉，这可能是一个相当简单的问题，但我不是 DBA，到目前为止一直在努力寻找有关此问题的任何答案。
谢谢
I have recently started working on a web application at a new company and am starting to bring in a few changes, for instance all my new code uses stored procedures rather than using a querystring in the code behind.
I recently discussed using Database schemas with my supervisor to tidy up our database and keep things manageable. The application I am working with is an intranet ASP.Net site with multiple sections for each department, I would like to implement a schema for each department so it is clear which procedures / tables belong to which parts of the application.
My question is would it be bad practice to add new tables / procedures etc into a database schema but leave everything else as it is then slowly add the existing tables to schemas? Or should we go through and add everything to schemas in one go?
Also is there any risk (performance or otherwise) to having some tables within a schema and some just within the database as they are now?
Sorry for what is probably a rather simple question but I'm not a DBA and have struggled to find any answers about this so far.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为随心所欲地迁移到模式的增量/重构方法是一个很好的方法。我认为它没有性能问题。最大的问题是记住开始对对象进行模式限定（即使在今天，您也应该这样做，因为这是性能的最佳实践），
而不是
如果您与模式限定一致，则应该没问题。如果你偷懒了，你最终会需要做更多的故障排除工作。
I think the incremental/refactoring approach of moving to schemas as you go is a fine approach. I see no performance issues from it. The biggest issue will be remembering to start schema qualifying your objects (which you should be doing anyway even today as it is a best practice for performance)
instead of
If you are consistent with your schema qualifying you should be fine. If you get lazy with it, you'll end up having more troubleshooting to do.
模式没有被广泛使用。您会发现一些数据库源代码控制和代码生成器与模式不能很好地配合。甚至数据库本身也对模式感到不舒服，例如，如果存在安全不匹配的可能性，就会拒绝缓存执行计划（模式可以有自己的安全设置）。
与触发器一样，最好完全避免模式。
Schema's are not widely used. You'll find some database source control and code generators don't play well with schema's. Even the database itself is uncomfortable with schema's and will, for example, refuse to cache an execution plan if there's a chance of a security mismatch (schema's can have their own security settings.)
Like triggers, schema's are best avoided altogether.