… 根据我的经验，这种情况通常发生在你正在操作的数据库或API不是你自己的时候，你无法控制它们。上游的ERP系统没有唯一键，或者它改变了列的名称，或者会计人员添加了一个自定义字段，或者会计系统声称有唯一标识符，但升级后改变了原本不应该改变的唯一行标识符，或者用户删除了一个记录并重新创建了相同名称的记录，现在它的ID不同了，所以你的报表数据库中的数据不再有正确的外键，一些数据必须从ERP系统与只有不可靠API的CRM进行交叉参考，而获取数据的唯一方法是从邮件中下载CSV报告文件，而该文件的字段名称与ERP系统不一致，无法可靠地关联数据，更糟糕的是，CRM中的这些字段是用户可编辑的，你200个销售人员中的一个决定使用自己的命名方案或者打错了字，我们有10种不同的方式来拼写“New York”、“new york”、“NY”、“newyork2”、“now york”，以及……
源讨论让数据库系统更易用原帖 154 条评论 · 导入时统计抱歉，但一个对连接（joins）有抵触情绪的人并不是SQL的非专家，而是一个完全的新手。答案就像其他编程语言一样。你必须学习这门语言的基础知识才能使用它。
完整原文把你的经验，加入这段讨论。
我遇到过几次这样的情况，多小时的处理会产生大量行，没有人愿意进一步排查。他们只想要去重的最终结果。 实际上，我最终创建了一个骨架表，它不仅有去重所需的适当约束。我还会创建大部分为空的行（除了所需的列键ID字段外都是空的），并带有他们期望的精确行。然后我会执行UPDATE <骨架> ... FROM <复杂的连接>。这是一种技巧，但如果没有人想重写多年前由咨询团队编写的流程，我只能做到我能做到的。
完整原文没有人有权利认为这一切都会很容易。如果你不喜欢与设计糟糕的数据库打交道，为什么不干脆和那些懂得如何使用数据库的人合作呢？同时，我有个坏消息要告诉你：没有人会替你完成这些艰难的工作。
完整原文当你有重复的数据以及数据不一致/完整性问题时，你的输出可能会出现重复的数据以及数据不一致/完整性问题。 这是形式的问题，而不是方法的问题。JOIN 是一种非常棒且定义明确的方法来聚合数据。如果数据的形式混乱，那么结果自然也会混乱。 > 我不感兴趣帮你调试那个7页的SQL查询，它建立在多个嵌套的SQL视图之上，导致结果行数太多 人们常说这种话，但SQL是一种非常高级的语言。 是的，调试一个大的SQL查询确实很糟糕。调试等效的代码通常更糟糕。我宁愿调试一个30行的查询，也不愿调试一个400行的Perl脚本，尽管它们做的是同样的事情。因为那才是真正的替代方案。 我曾经手动聚合过数据，杂乱的数据，用过awk、perl、python……这要糟糕得多。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。