标签：历史记录 一张 数据库 user 数据量 张表 变化 id 经验总结

考虑如下表结构：
table: device
columns: id, create_time, user_id
这是一张设备表，设备是每一行的id都唯一对应一个用户user_id，而这个user_id是会随着系统的变化而变化的。

------------------------------------------------------------------------------

这种场景在我们设计系统时是很常见的，一般有可能如上所示，是一个固定内容的字段对应其它随时会发生变化的其它字段。这里其实有两种设计方法，一种是，这一张表里，id唯一对应一个设备，user_id变化了就更新（如果需要了解之前存过哪些user_id，那就单独再存到历史记录表中）；另一种是，这张表的id就对应关系，而不是具体的设备，当user_id+mac发生了变化，那么insert一对新的user_id+mac，之前的数据不动。

------------------------------------------------------------------------------

对于后一种，只创建一张表，但如果这里面的内容频繁变化，那么这张表的数据量将会呈指数级增加，对于频繁修改和查询，这种设计会导致数据量增大或者变化频次增高后系统无法承受的查询延迟。只有当这张表的内容在整个系统运行期间不变或者极少变化时可以考虑采用这种一张表的做法。更多情况下，我们适宜采用前一种模式，即变化表/最新状态表内容存到一起，方便应对快速的增删改查，而历史状态记录到另一张表中，历史数据表的存放与查询其实不如前者那么重要，如果数据量较大，我们可以采用异步、或者进一步将表拆分等手段进行处理。

标签：历史记录,一张,数据库,user,数据量,张表,变化,id,经验总结
来源： https://www.cnblogs.com/bruceChan0018/p/15423525.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。