- 主题:请教多对多表设计问题
你这样设计容易丢失原始信息，后面没法为数据清洗提供基础数据了。
理论上原始设备的时间值可能是错的，因为刚开机还没校准。
设备ID与人员ID的绑定关系可能是重合的，因为有人忘了解绑，有人忘了绑定，有人绑了多设备。
人员ID可能就输错了，或者重启后丢失人员ID。
绑定可能绑了多次。解绑也一样。可能解绑与绑定不能成对。
穿戴设备里的原始数据还可能多次反复上传造成冗余，因为现场3G信号不好，或者基站拥堵，或者设备反复重启，或者app发疯，等等。
这些错误数据可能通过后续的清洗算法修正或者抛弃。现场处理会一团乱麻。
【 在 Yuguo15666 的大作中提到: 】
: 从你描述的业务情况来看，人员和设备并没有稳固的分配关系，只是在一次测试中临时使用产生关系，所以不需要人员设备关系表。再假定一个人只属于一个组：
: 实体表：
: 设备 （ID，名称，.....）
: 小组 （ID，名称，.....）
: 人员 （ID，名称，所属小组ID，性别，...）
: 测试活动（ID，测试时间，测试员人员ID，测试用设备ID，测试结果值1，测试结果值2，.......）
: 关系表：没有多对多关系，不需要独立关系表
: - 来自 水木社区APP v3.5.7
--
修改:lipp FROM 123.103.9.*
FROM 123.103.9.*
我感觉你不把绑定、解绑这些现场业务搞清晰的话，玩数据没啥用。
只要现场业务通顺，时序数据上传了都没丢，后面怎么玩都好办，反正都存在云服务器里跑不了。前面讨论的这些架构，你挨个全试一遍嘛，自然知道好坏了。
【 在 annodom 的大作中提到: 】
: 现在就很麻烦了。。。因为以前数据是通过独立线程直接保存到数据库的。msg只携带了chipID和业务数据。。。
: 现在想增加人和小组字段，但是独立线程的数据在保存之前是没法获取这些信息的。
: 在想要不要再建一个中间表：id，小组id，人员id，设备id（chipid）来解决
: ...................
--
FROM 123.103.9.*
你设备就没带人员识别功能（比如人员ID卡扫描，不扫不能用，或者类似微信绑定手机号），你怎么玩“一把存”？
一定要把业务流程搞清楚啊。你硬件支撑不了的业务流程，一定无法产生你想要的业务数据。
【 在 annodom 的大作中提到: 】
: 啊。。。
: 就是懒了嘛。。。想一把存进去，然后想咋找就咋找。。。
--
FROM 123.103.9.*