手动关系发现无法扩展。即使使用SQL也不行。

Source: Dev.to

成对比较的爆炸

让我们从大多数团队从未明确写下的数学公式开始。

如果你有：

• 100 张表
• 每张表有 50 个候选字段

这就是 5,000 个字段。

要检查潜在的关系，你比较的不是表，而是字段。这意味着：

5,000 × 5,000 = 25,000,000

种可能的比较。

即使你极力缩小搜索空间，数字仍然非常庞大。大型企业在系统中常常拥有数万字段，手动探索根本跟不上组合增长的速度。

暴力比较为何不可行

最朴素的做法显而易见：

“把字段之间的值进行比较，看看有什么匹配。”

在小规模时，这种方法有效。但在真实规模下，它会崩溃。

• 全表扫描成本高
• 不同值的数量激增
• 网络和计算费用飙升
• 执行时间难以预测

在许多环境中，完整比较不仅慢，而且在运营上几乎不可能。这也是团队悄悄回避它的原因，即使他们知道这样会更“正确”。

“手动抽样” 的虚假承诺

为了解决这个问题，团队往往妥协，进行抽样：

• 100 行
• 1,000 行
• “随便觉得代表性的” 行数

然后肉眼观察重叠。这看似务实，却引入了一类新问题。

• 小样本会错过稀有但关键的关系
• 偶然的重叠会被误认为有意义
• 负向结果缺乏结论性
• 没有人知道何时可以有信心

手动抽样没有统计依据，缺乏可重复性，也没有可辩护的停止点。它用人为偏差取代了计算限制。

SQL 很强大——但它是错误的抽象层

SQL 在执行已知逻辑方面表现卓越，却不适合发现未知结构。关系发现要回答的问题包括：

• 哪些字段可能有关联？
• 这是什么类型的关系？
• 信号有多强？
• 是包含、等价还是巧合？

这些不是查询问题，而是推理问题。试图用临时的 SQL 来解决，就像用电子表格去逆向工程编译器。

关系发现是算法问题

在大规模下，关系发现需要：

• 特征提取，而不是原始比较
• 智能剪枝，而不是暴力搜索
• 概率推理，而不是直觉判断
• 可重复性，而不是一次性分析

这正是手动方法失败的原因——不是因为工程师效率低下，而是因为问题本身属于不同的类别。除非团队把关系发现视为一种算法能力，而不是手动任务，否则 SQL 只能充当调试工具，而不是解决方案。猜测的循环将继续下去。