这种场景怎么设计比较合理

licy
上网不便, msg收不到 2018-10-08 字数 536

有这么个场景:

完成一件事情之后要并行做B、C、D。。。好几件事,需要跟踪一下BCD。。这些事情有没有完成,数据库里怎么记比较方便应用处理?

方案1:设计一个大的整数,每一位代表一个事情,如第一位代表B、第二位代表C、第三位代表D,以此类推。这一位是0代表未完成,1代表已经完成或者不需要做,这样当所有位数都是1的话就做完了

方案2:每件需要做的事情记一条记录,状态0代表未完成,1代表不需要做或者已经完成,当select count(1) where status = '0' 为0的时候,所有事情就都做完了

事件会比较多,一个数据库里可能会有几百万条,两个方案好像比较一般,还有其他方案吗?

Database 数据库技术
7 个回复
liuxueshen
rock 2018-10-08

如果用关系数据库不推荐方案一,记录级的互锁就抵消并行节省的时间了,

还不如串行处理呢。

如果是用C++之类的编程,专门做个消息处理模块用方案1就不错。

【 在 licy (上网不便, msg收不到) 的大作中提到: 】

: 标  题: 这种场景怎么设计比较合理

: 发信站: 水木社区 (Mon Oct  8 21:24:55 2018), 站内

: 有这么个场景:

: 完成一件事情之后要并行做B、C、D。。。好几件事,需要跟踪一下BCD。。这些事情有没有完成,数据库里怎么记比较方便应用处理?

: 方案1:设计一个大的整数,每一位代表一个事情,如第一位代表B、第二位代表C、第三位代表D,以此类推。这一位是0代表未完成,1代表已经完成或者不需要做,这样当所有位数都是1的话就做完了

: 方案2:每件需要做的事情记一条记录,状态0代表未完成,1代表不需要做或者已经完成,当select count(1) where status = '0' 为0的时候,所有事情就都做完了

: 事件会比较多,一个数据库里可能会有几百万条,两个方案好像比较一般,还有其他方案吗?

: --

Knightmare
梦醒时分 2018-10-08

方案1违反了第一范式

方案2我没看懂,应该是很反直觉的。

其实最简单的方案就是专门做个事件表放事件BCD,表应该包含ACCIDENT_ID, SUBACCIDENT_ID, STATUS几个字段,并且unique(ACCIDENT_ID, SUBACCIDENT_ID)

最后select count(*) from 表 where ACCIDENT_ID=x and SUBACCIDENT_ID in ('B', 'C', 'D') and STATUS='F'

看是不是等于3吧

【 在 licy (上网不便, msg收不到) 的大作中提到: 】

: 标  题: 这种场景怎么设计比较合理

: 发信站: 水木社区 (Mon Oct  8 21:24:55 2018), 站内

: 有这么个场景:

: 完成一件事情之后要并行做B、C、D。。。好几件事,需要跟踪一下BCD。。这些事情有没有完成,数据库里怎么记比较方便应用处理?

: 方案1:设计一个大的整数,每一位代表一个事情,如第一位代表B、第二位代表C、第三位代表D,以此类推。这一位是0代表未完成,1代表已经完成或者不需要做,这样当所有位数都是1的话就做完了

: 方案2:每件需要做的事情记一条记录,状态0代表未完成,1代表不需要做或者已经完成,当select count(1) where status = '0' 为0的时候,所有事情就都做完了

: 事件会比较多,一个数据库里可能会有几百万条,两个方案好像比较一般,还有其他方案吗?

: --

Madlee
无竹居士 2018-10-09

项目管理里很多这样的例子吧,肯定不会用1。

kod
CtrlAltDelete 2018-10-09

存储用方案2,查询应该用exists,如果只是你描述的查询内容

方案1对于并行的几件事来说会有并发的问题,而且未来扩展起来也会是问题

【 在 licy (上网不便, msg收不到) 的大作中提到: 】

: 有这么个场景:

: 完成一件事情之后要并行做B、C、D。。。好几件事,需要跟踪一下BCD。。这些事情有没有完成,数据库里怎么记比较方便应用处理?

: 方案1:设计一个大的整数,每一位代表一个事情,如第一位代表B、第二位代表C、第三位代表D,以此类推。这一位是0代表未完成,1代表已经完成或者不需要做,这样当所有位数都是1的话就做完了

: ...................

chinaclaw
有生皆苦 2018-10-16

方案一其实就是标记位,无论是放在一个字段里还是拆开多个字段,都是列模式。

方案二是行模式。

从扩展性上看肯定是方案二比较好,

从安全性看,并发大时方案一会有问题。

从读取效率看,方案一较好。

【 在 licy (上网不便, msg收不到) 的大作中提到: 】

: 有这么个场景:

: 完成一件事情之后要并行做B、C、D。。。好几件事,需要跟踪一下BCD。。这些事情有没有完成,数据库里怎么记比较方便应用处理?

: 方案1:设计一个大的整数,每一位代表一个事情,如第一位代表B、第二位代表C、第三位代表D,以此类推。这一位是0代表未完成,1代表已经完成或者不需要做,这样当所有位数都是1的话就做完了

: ...................

yourgf2
yourgf死了,我是二代 2018-10-24

还是建议用方案2比较好一些

然后再加一个字段Parent_Node_ID之类的,形成一个链表

这个字段加上索引的话,百万记录查询速度不会有什么太大问题

【 在 licy (上网不便, msg收不到) 的大作中提到: 】

: 有这么个场景:

: 完成一件事情之后要并行做B、C、D。。。好几件事,需要跟踪一下BCD。。这些事情有没有完成,数据库里怎么记比较方便应用处理?

: 方案1:设计一个大的整数,每一位代表一个事情,如第一位代表B、第二位代表C、第三位代表D,以此类推。这一位是0代表未完成,1代表已经完成或者不需要做,这样当所有位数都是1的话就做完了

: ...................

licy
上网不便, msg收不到 2018-10-27

方案二的话有个场景处理起来麻烦些,就是要把事情做完的所有数据移走

【 在 licy (上网不便, msg收不到) 的大作中提到: 】

: 标  题: 这种场景怎么设计比较合理

: 发信站: 水木社区 (Mon Oct  8 21:24:55 2018), 站内

: 有这么个场景:

: 完成一件事情之后要并行做B、C、D。。。好几件事,需要跟踪一下BCD。。这些事情有没有完成,数据库里怎么记比较方便应用处理?

: 方案1:设计一个大的整数,每一位代表一个事情,如第一位代表B、第二位代表C、第三位代表D,以此类推。这一位是0代表未完成,1代表已经完成或者不需要做,这样当所有位数都是1的话就做完了

: 方案2:每件需要做的事情记一条记录,状态0代表未完成,1代表不需要做或者已经完成,当select count(1) where status = '0' 为0的时候,所有事情就都做完了

: 事件会比较多,一个数据库里可能会有几百万条,两个方案好像比较一般,还有其他方案吗?

: --