我尝试让技术人员使用数据库时，有很大一部分（不是100%，但可能是80%）的挫败感来自于他们很难理解连接（JOIN）。人们无休止地想要一些技巧、变通方法和非规范化的数据结构，原因只有一个——他们不想去思考连接。这并不是出于性能原因，也不是出于其他任何原因，只是因为想象一个有很多列的大表更容易。我确实能理解这种抵触情绪，但我并不认同的是：为什么到了2024年，计算机还不能替我处理多表连接呢？除非你的数据库结构真的非常糟糕，否则跨多个表连接应该只有一两种真正合理的方式。比如，假设我有放在盒子里的苹果，盒子里的苹果又放在房子里。我有一个苹果表、一个盒子表和一个房子表。苹果表有box_id，盒子表有house_id。现在我想找出所有在房子里的苹果。做两次连接就可以了，很酷。…
源讨论让数据库系统更易用原帖 154 条评论 · 导入时统计把你的经验，加入这段讨论。
真正的问题并不是连接表A和表B的方式有组合爆炸式的可能，而是除非连接被完全明确，否则这些方式大多会产生不同的结果。你的工具需要能够检测这些模糊的情况，并要么失败，要么提示用户说明他们的意思。无论如何，用户都无法避免理解连接的概念。
完整原文大多数数据库都有外键的概念。你可以声明表之间的关系。然后你可以编写一个脚本来查询这些元数据，从而为你编写连接语句。我二十多年前就做过类似的事情。
完整原文> 最后我自己写了一个连接工具，可以自动在模式中查找不同表之间的路径，但自己开发这样的东西看起来很荒谬。 我的意思是，我认为问题只是因为可能的路径太多，所以无法自动化。 如果你想将员工表与建筑物表连接，是他们今天分配的办公桌位置，还是两年前分配的办公桌位置，还是他们团队所在的位置（尽管他们远程工作），还是他们最后一次刷卡进入的位置？ 当然你可以开发一个工具，根据外键找到所有可能的连接，但除非你了解这些表的含义，否则你怎么知道哪个是正确的呢？如果你了解这些表的含义，那么自己写出连接语句是微不足道的。 > 除非你的模式真的乱七八糟，否则应该只有一种或两种真正合理的跨多个表的连接方式。 在我的经验中，…
完整原文> 人们无休止地想要一些技巧、变通方法和非规范化的数据结构，原因只有一个——他们不想去思考连接（JOIN）。这并不是出于性能原因，也不是出于其他任何原因，只是因为想象一个有很多列的大表更容易。 这是因为令人难以置信的是，大多数开发人员并不了解SQL，也不想学习它。这是一门极其简单的语言，应该能让一个有能力的人在一天内掌握基本知识，也许一周内就能非常熟练。 顺便说一句，你可以创建视图（非物化视图）来满足你想要的查询。对此的反对意见是这会减慢开发速度，但开发人员不懂如何进行连接也会减慢开发速度。
完整原文> 除非你的模式真的乱七八糟 所以大多数已经超越了多个应用程序的企业模式。通常是由于时间限制、缺乏数据库管理员和复杂的业务需求。Excel成为数据库之王是有原因的。
完整原文你可以让ORM通过一些注解或其它方式帮你解决这个连接问题，比如预加载等。 但这只是简单的情况，通常你想要更复杂的东西，连接的顺序或你选择的关键词以及你希望结果如何排序，都会影响你特定模式和特定数据库引擎的性能。 一旦你超出简单的情况，关系型数据库管理系统（RDBMS）的管理和查询就是一个相当深奥且需要经验的领域。你可以将更多内容放在应用代码中，但这会产生大量通信，并且在性能方面可能比团队中有真正擅长数据库的人要差。
完整原文你应该了解一些基本的数据库内部知识。特别是索引的数据结构，主索引和次索引的区别，连接算法，页大小为8KiB等。 这些知识能让你理解为什么大多数连接操作非常慢，因为每页数据库只包含1%对查询算法有用的信息。 这将帮助你理解人们为什么会做诸如放入数组列或使用宽表等事情的原因。
完整原文> 除非你的模式真的非常糟糕，否则跨多个表连接应该只有一种或两种真正合理的方式。比如，假设我有放在盒子中的苹果，放在房子中的盒子。我有一个苹果表，一个盒子表，和一个房子表。苹果有box_id，盒子有house_id。现在我想找出所有在房子中的苹果。做两次连接，很酷。但似乎每个人都是手动编写这个过程，这意味着crud应用程序最终会有数千个几乎相同的查询，这些查询只是无聊地写出需要应用的连接链。 你主要是在描述自然连接。它不会读取你的思想并自动连接你的表，但它会自动使用共享列作为连接键，并从结果中删除重复的键。 任何“自动”解决方案的问题在于像修改日期这样的东西，它们可能存在于多个表中但不共享。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。