在RDMBS中检测多到多的关系的程序方法是什么？

Question

我目前正在忙于制作一个Python Orm，该ORM通过内省从RDBM中获取所有信息（如果我在其他方面对此感到满意，我会选择Xrecord） - 意思是，最终用户只告诉哪些表/视图要列出哪些表/视图查看，ORM自动完成其他所有操作（如果 制作 您实际上写了一些东西，而不是在寻找奇怪的东西和危险的冒险，这是一个错误）。

其中的主要部分是检测关系，只要数据库具有所有相关的约束，您根本没有命名约定 - 我希望能够与任何具有自己的疯狂DBA制作的数据库一起工作有关列和表格应该命名的视图。而且我陷入了许多一对一的关系。

首先，可以 复合键. 。然后，可以 MTM与三个或更多表的关系. 。然后，MTM中介表可能有自己的 除了钥匙以外的数据 - 与所有表相关联的一些数据。

我想要的是一种方法，可以编程地检测表x是一个中间表绑定表A和B，并且它具有的任何非键数据都必须同时属于A和B（如果我从A内更改一个常见属性，它应该影响b）中的相同属性。是否有常见算法可以做到这一点？还是至少要在80％的情况下进行猜测（前提是DBA是理智的）？

Answer 1

到目前为止，我看到唯一一项涵盖了两个以上表的技术。 假定表X与表y相关，并且仅当x引用y不超过一个表时。 那是：

“零桌”是指X包含Y的外键。没什么大不了的，这就是我们多对方的方式。

“一个表格”是指有一个表Z本身具有外键引用表X（这些很容易找到），还有一个外键引用表y。

这降低了特征的范围，要寻找很多东西（我们不必关心中介表是否具有其他属性），并且涵盖了MTM关系中捆绑在一起的任何数量的表。

如果有一些有趣的链接或其他方法，我愿意听到它们。

Answer 2

如果您必须问，您不应该这样做。我并不是说这是残酷的，但是Python已经有几个经过良好测试且广泛使用的优秀ORM。例如，sqlalchemy支持 autoload=True 定义表格读取表定义的表格时的属性 - 包括直接从数据库中读取的所有内容。当其他人已经完成99.9％的工作时，为什么还要重新发明轮子？

我的答案是选择一个Python Orm（例如SQLalchemy），并为此添加任何“缺失”功能，而不是从头开始。如果事实证明这是一个好主意，请将您的更改释放回主项目，以便其他所有人都可以从中受益。如果它不像您希望的那样无法正常工作，那么至少您已经使用了许多其他程序员可以为您提供帮助的普通ORM。

Answer 3

从理论上讲，任何带有多个外国钥匙的桌子本质上都是多对多的关系，这使您的问题变得琐碎。我怀疑您需要的是何时使用MTM模式（而不是标准类）的启发式方法 目的 模型。在这种情况下，检查您选择的模式的局限性是什么。

例如，您可以通过将列表作为两种类型的对象上的属性来建模简单的MTM关系（两个表，无属性）。但是，如果您有有关关系本身的其他数据，列表将不够。因此，只有两列的表调用此模式，均为外键。