Open pengkobe opened 7 years ago
由于 app 离线应用场景较多，用户又有着迫切的升级需求，需要根据各个离线应用场景定制解决方案，达到离线使用稳定，数据不丢失
系统-->房间-->设备
需要保存最近一次更新的数据
在前端内存中需要维护一个大对象，在有网络时使用网络数据，没网络时使用离线缓存数据
平台用户项目: n+ 项目用户项目: 1~3 集团用户:10~100 | 系统 | --> | 房间 | --> | 设备 | 10 * 10 * 40 * 20 = 8000 个数据点 采集平均: 4 * 6 * 10 * 12 = 2860 个数据点 手工录入平均: 2 * 6 * 10 * 5 = 600 个数据点
直接存储这样的大对象显然有点不合理，特别对平台级用户来说。
解决方案 （0）最小化设计，只对手工录入的场景进行考虑，不考虑实时采集场景 （1）在本地维护一个数据库，可以实现统计各 App 端对 indexDB 的支持情况，然后再做分析 （2）使用 localstorage 方法，App 开启时维护一个内存结构 （3）不对离线进行处理，只对打开后断网进行处理
用户可能在多个地点进行录入，录入时长，App 在黑屏过久再打开时会重启
需要对用户录入的数据进行热存储，目前通用的方案是使用 localstorage。 localstorage 的平均大小为 4 M，可以存储字符数: 4 * 1024 * 1024 / 2 = 2097152 理论上可以存储 209+万中文字符，相当于几部长篇小说
4 * 1024 * 1024 / 2 = 2097152
209+
数据量 O(n)， 使用 hash 结合 userid 做索引。
由于 app 离线应用场景较多，用户又有着迫切的升级需求，需要根据各个离线应用场景定制解决方案，达到离线使用稳定，数据不丢失
基础信息
系统-->房间-->设备实时数据
需要保存最近一次更新的数据
手工录入
用户在结束巡检后无法看到数据
在前端内存中需要维护一个大对象，在有网络时使用网络数据，没网络时使用离线缓存数据
直接存储这样的大对象显然有点不合理，特别对平台级用户来说。
用户未做完一次巡检，而不小心关闭 APP，导致数据丢失
需要对用户录入的数据进行热存储，目前通用的方案是使用 localstorage。
localstorage 的平均大小为 4 M，可以存储字符数:
4 * 1024 * 1024 / 2 = 2097152理论上可以存储
209+万中文字符，相当于几部长篇小说通讯录
协同通过通讯录识别消息发送者
数据量 O(n)， 使用 hash 结合 userid 做索引。