什么是以编程方式检测RDBMS中多对多关系的方法?

时间:2010-10-10 19:59:47

标签: python orm metaprogramming introspection relationships

我目前正在忙着制作一个Python ORM,它通过内省从RDBMS获取所有信息(如果我在其他方面对它感到满意,我会使用XRecord) - 意思是,最终用户只告诉哪些表/ views要查看,ORM会自动执行其他所有操作(如果它使你实际上写了一些东西而且你不是在寻找奇怪的东西和危险的冒险,那就是一个错误)。

主要部分是检测关系,只要数据库具有所有相关约束并且您根本没有命名约定 - 我希望能够让这个ORM与任何疯狂的DBA制作的数据库一起工作对于列和表应该命名的内容有自己的看法。而且我被困在多对多的关系中。

首先,可以有复合键。然后,可能存在与三个或更多表的MTM关系。然后,MTM中间表可能有自己的数据,而不是键 - 它连接在一起的所有表共有的一些数据。

我想要的是一种以编程方式检测表X是绑定表A和B的中间表的方法,以及它所拥有的任何非关键数据必须同时属于A和B(如果我更改了公共属性)从A中,它应该影响B)中的相同属性。有没有通用的算法呢?或者至少在80%的案例中做出正确的猜测(假如DBA是理智的)?

3 个答案:

答案 0 :(得分:1)

如果你不得不问,你不应该这样做。我并不是说这是残酷的,但是Python已经有几个经过充分测试和广泛使用的优秀ORM。例如,SQLAlchemy在定义表时支持autoload=True属性,这些表使得它直接从数据库读取表定义 - 包括您要询问的所有内容。当其他人已完成99.9%的工作时,为什么要重新发明轮子?

我的回答是选择一个Python ORM(例如SQLAlchemy)并为其添加任何“缺失”功能,而不是从头开始。如果结果是个好主意,请将更改发布回主项目,以便其他人都可以从中受益。如果它没有像你希望的那样工作,至少你已经使用了许多其他程序员可以帮助你的通用ORM。

答案 1 :(得分:0)

理论上,任何具有多个外键的表本质上都是多对多关系,这使得您的问题变得微不足道。我怀疑你需要的是在对象模型中何时使用MTM模式(而不是标准类)的启发式方法。在这种情况下,请检查您选择的模式的限制。

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

答案 2 :(得分:0)

到目前为止,我看到唯一一种涉及两个以上表格的技术。 假设表X与表Y相关,当且仅当X被引用到Y不超过一个表时。即:

“Zero tables away”意味着X包含Y的外键。没什么大不了的,这就是我们检测多对一的方式。

“一桌之外”意味着有一个表Z,它本身有一个外键引用表X(这些很容易找到),以及一个外键引用表Y.

这减少了很多特征的范围(我们不必关心中间表是否有任何其他属性),并且它涵盖了在MTM关系中捆绑在一起的任意数量的表。

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