我目前正忙于制作一个 Python ORM，它通过自省从 RDBMS 获取其所有信息（如果我在其他方面对它感到满意，我会选择 XRecord）——意思是，最终用户只告诉哪些表/视图看一下，ORM 会自动完成其他所有事情（如果它让你真正写了一些东西，而你不是在寻找奇怪的东西和危险的冒险，那就是一个错误）。
其中的主要部分是检测关系，前提是数据库具有所有相关的约束并且您根本没有命名约定——我希望能够让这个 ORM 与任何疯狂的 DBA 制作的数据库一起工作，该数据库有他自己的关于列和表应该命名的视图。我被困在多对多的关系中。
首先，可以有复合键。然后，可以存在与三个或更多表的 MTM 关系。然后，一个 MTM 中间表可能除了键之外还有自己的数据——一些数据对于它绑定在一起的所有表都是通用的。
我想要的是一种以编程方式检测表 X 是绑定表 A 和 B 的中间表的方法，并且它拥有的任何非键数据都必须属于 A 和 B（如果我从 A 中更改公共属性，它应该影响 B) 中的相同属性。有没有通用的算法来做到这一点？或者至少在 80% 的情况下做出正确的猜测（前提是 DBA 是理智的）？
如果你不得不问，你不应该这样做。我并不是说这很残忍，但 Python 已经有几个经过充分测试和广泛使用的优秀 ORM。例如，SQLAlchemyautoload=True在定义表时支持该属性，使其直接从数据库中读取表定义（包括您询问的所有内容）。别人已经完成了 99.9% 的工作，为什么还要重新发明轮子？
我的答案是选择一个 Python ORM（例如 SQLAlchemy）并向其中添加任何“缺失”的功能，而不是从头开始。如果结果证明是个好主意，请将您的更改发布回主项目，以便其他人可以从中受益。如果它没有像您希望的那样工作，至少您已经在使用许多其他程序员可以帮助您的通用 ORM。
从理论上讲，任何具有多个外键的表本质上都是多对多关系，这使您的问题变得微不足道。我怀疑您需要的是在对象模型中何时使用 MTM 模式（而不是标准类）的启发式方法。在这种情况下，请检查您选择的模式有哪些限制。
例如，您可以通过将列表作为两种类型对象的属性来对简单的 MTM 关系（两个表，无属性）建模。但是，如果您有关于关系本身的其他数据，则列表是不够的。因此，仅对具有两列且均具有外键的表调用此模式。
到目前为止，我看到的唯一一种技术涵盖了两个以上的相关表。假设表 X 与表 Y 相关，当且仅当 X 引用到 Y 的距离不超过一个表。那是：
“零表”意味着 X 包含 Y 的外键。没什么大不了的，这就是我们检测多对一的方式。
“One table away”意味着有一个表 Z，它本身有一个外键引用表 X（这些很容易找到）和一个外键引用表 Y。
这减少了寻找很多特征的范围（我们不必关心中间表是否有任何其他属性），并且它涵盖了在 MTM 关系中捆绑在一起的任意数量的表。
如果有一些有趣的链接或其他方法，我愿意听。