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

Question

这个问题可能更适合于程序员.stackexchange.如果是,请迁移.

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

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

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

Answer 1

规范化数据库本身就是一种艺术形式.
如果正确构建连接,则只能获取所需的列.
运行具有多个表的数百万条记录的查询并加入所需的字段应该快得多,如果您说一个或两个表包含所有记录,那么它会更快.在第二个例子中,您正在检索所有数据,并通过它进行排序将是一个编码噩梦.
MySQL非常好只检索请求的数据.
仅仅因为查询很长并不意味着它更慢.
我已经看到超过20行代码的查询语句非常快.

对您编写的查询有信心,如果您不编写测试脚本,请自行尝试.

Answer 2

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

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

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

前段时间有一个相关的问题关于包含多个连接的SQL语句如何工作？也值得研究一下.

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