上下游依赖 这种er关系 在mysql 等关系型数据库中 如何设计 存储

在任务调度系统中,为存储任务的上下游依赖关系,文章探讨了多种设计方案。包括将依赖关系作为任务属性存储、仅存储上游依赖以及建立独立的依赖关系表。最终推荐使用独立的依赖关系记录表,其结构包含自增主键、上游任务ID和下游任务ID,并对这两列创建索引,以方便查询并避免数据冗余。
摘要由CSDN通过智能技术生成

问题场景: 在任务调度系统中,每个任务 既有上游 ,也有下游。如何设计 底层存储的表结构 支撑这种存储。


解决方法:


一. 采用图形 数据库 neo4j,每个节点 代表一个任务,节点之间的 边 (带有方向箭头) 表示 任务之间的依赖关系。 



二. mysql等关系型数据库。

       设计1 : 将 上下游依赖关系 作为 任务的属性 存储起来。 即:  任务id(主键)、任务名称、任务的上游id list、任务的下游id list。

                        优点: 这是最容易想到的方案。 但知觉告诉我不是很佳的方案,而且也显然不满足 3NF的设计原理。

                        缺点:


       设计2:  只存储任务的上游依赖。  即 任务id(主键)、任务名称、任务的上游id list。


       设计3:  将 任务之间的 依赖关系 单独 作为一个记录表 保存。依赖关系记录表的 表结构:自增主键id、上游任务id、下游任务id。同时 将 第二列、第三列都增加索引。

                       推荐设 计3.

                               优点: 因为依赖关系是 相对的,如果A和B有依赖关系,显然上游任务id就是A,下游任务id就是B。作为一条记录 insert 记录表。

                        如何查询 A的所有下游,则 select  下游任务id  from 表 where 上游任务id=‘A’。 如果记

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值