sql – 在实践中有多少连接是可行的

前端之家收集整理的这篇文章主要介绍了sql – 在实践中有多少连接是可行的前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
这个问题可能更适合于程序员.stackexchange.如果是,请迁移.

我目前正在思考典型数据模型的复杂性.每个人都知道数据模型应该被标准化,但另一方面,标准化数据模型将需要相当多的连接来重新组装数据.并且连接可能是昂贵的操作,具体取决于所涉及的表的大小.所以我想弄清楚的问题是人们通常会如何进行这种权衡?即实际上,在设计数据模型时,您会发现在典型查询中可以接受多少个连接?在单个查询中计算多个联接时,这将特别有趣.

举个例子,假设我们有拥有房屋的用户,其中有房间,有抽屉,其中包含物品.通过上面解释的用户,房屋,房间,抽屉和物品的表格对其进行简单的标准化,后来要求我在获得属于@R_502_359@的所有项目时加入五个表格.这对我来说似乎非常复杂.

很可能也会涉及表格的大小.使用少量数据连接五个表并不像具有数百万行的三个表一样糟糕.或者这个考虑是错误的?

解决方法

reasons for the Database Normalizations,我已经看到超过20个表和子查询连接在一起的查询,工作很长时间.我发现规范化的概念是一个巨大的胜利,因为它允许我引入新功能添加到现有的工作应用程序中,而不会影响到目前为止的工作部分.

数据库具有不同的功能,使您的生活更轻松:

>您可以为最常用的查询创建视图(尽管这不是视图的唯一用例);
>某些RDBMS提供了Common Table Expressions(CTE),允许您使用命名子查询和递归查询;
>某些RDBMS提供了扩展语言(如PL / sql或PL / pgsql),允许您开发自己的函数来隐藏模式的复杂性,并仅使用API​​调用来操作数据.

前一段时间有一些相关的问题在How does a SQL statement containing mutiple joins work?也可能值得研究一下.

使用规范化数据库开发应用程序更容易,“通过正确的方法,您可以通过视图/函数隔离您的模式,并使您的应用程序代码免受模式更改的影响.如果您要进行非规范化设计,可能会发生设计更改会影响大量代码,因为非规范化系统往往会以变更可能性为代价进行高性能优化.

原文链接:https://www.f2er.com/mssql/76306.html

猜你在找的MsSQL相关文章