您说的对。。。

主要是设备都是在野外使用，而且使用时间很短，3分钟左右现场轮换这种。。。

所以想在数据采集的时候把chipid携带者，整理的时候根据chipid再找到关联的人，便于分析

【 在 oldwatch 的大作中提到: 】
: 如果多对多关联是发生在时间维度上的话（领了，还了，又领了，...）
: 未必需要在基础表里持久记录/维护，一般是记录一个变迁的流水
: 直接在生成的业务数据里头把当前使用人/当前分组统统记下就完事了
: ...................
--
FROM 39.144.34.*

人和小组的关系如果相对静止

那业务数据关联到人就够了，反正基础表里有人-组关联，不用冗余一个小组信息

【 在 annodom 的大作中提到: 】
: 感谢您和几位大佬的指点。结合自己查询的资料，感觉越来越清晰了。
: 目前是：
: 3个实体表：人、小组、设备
: ...................
--
FROM 222.70.17.*

谢谢您的回复，很清晰。

实际是任何设备以及分组都是不固定的，

现在的设计就是3个实体表一个业务数据表，数据表中包含3个实体字段。如下：
     设备 （ID，名称，.....）
     小组 （ID，名称，.....）
     人员 （ID，名称，性别，...）
     测试活动（ID，chipID, msgID, 测试时间，测试员人员ID，测试用设备ID，测试小组ID, 测试结果值1，测试结果值2，.......）


遇到的问题就是以前业务数据过来后直接丢到数据库(时间、chipID \msgID\业务数据。。。。)，现在表修改了就要把3个实体字段与数据字段合并再插入到数据库。不知道这样会不会影响数据插入和查询的效率。


【 在 Yuguo15666 的大作中提到: 】
: 从你描述的业务情况来看，人员和设备并没有稳固的分配关系，只是在一次测试中临时使用产生关系，所以不需要人员设备关系表。再假定一个人只属于一个组：
: 实体表：
:     设备 （ID，名称，.....）
: ...................
--
修改:annodom FROM 39.144.34.*
FROM 39.144.34.*

你这样设计容易丢失原始信息，后面没法为数据清洗提供基础数据了。

理论上原始设备的时间值可能是错的，因为刚开机还没校准。
设备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.*