创建模式类型来组织表的关系是个好主意吗
创建一个模式类型来分离表关系是一个好主意吗？我想当您浏览 SSMS 中的表时，您会看到它们按架构类型分组在一起。但这值得吗？有人在现实场景中有这方面的经验吗？
Is it a good idea to create a schema type to separate the table relationships. I guess when you are browsing the tables in SSMS you will see them group together by schema type. But is it worth the trouble? Anyone with experience with this in real world scenarios?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我通常发现这比它提供的任何帮助更麻烦。您如何处理与多个区域相关的表格？当一张表似乎属于一个区域但后来迁移到应用程序的另一个区域时，会发生什么情况？您是否更改其架构并重构所有代码？
当对象之间存在非常清晰的边界时，我使用了多个模式来进行描述，但通常与图表中的边界不同。一个例子是仅用于 DBA 支持的对象。如果实际应用程序本身不使用它们，我可能会将它们放入自己的架构中。
I've generally found that to be more of a hassle than any help it's provided. What do you do with tables that are relevant to multiple areas? What happens when a table seems to belong to one area but later migrates to another area of the application? Do you change its schema and refactor all of your code?
I have used multiple schemata to make delineations when there is a VERY clear boundary between objects, but usually not something like what you have in your diagram. One example is objects which are used just for DBA support. I might put those into their own schema if they aren't used by the actual application itself.