关于一个数据表优化的问题

时间:2021-10-26 12:19:07
我有一张表,表名,info,记录了一些数据,这些数据是有时效的。时间一到,这条信息就删除。当然,不是真正的删除,就是传说中的进入历史库。

我考虑两种方式 。一是在info里加一个列,列名,expired,0表示过期,1表示有效。如果结束时间一到,则把这个列写为0,表示此条已经过期,系统在查询时,就只查询所有expired=1的记录。info这个表的数据行当然会越来越多。也许1K,也许5K,也许2W.。。。

另外一种方式时,一个info表,一个history表。info表里某条数据结束时间一到,就先复制数据至history里,然后将info里的这一条数据删除。

当然,info和history里的数据显然都是独立的,不会重复。我后面要查询某一个内容,部分数据就在info里查,部分数据就在history里查,这个查询语句就会复杂一点,就是我昨天提的问题,在onlyliu的帮助下,已经解决了。

如果用第一种方式,则查询时就会很简单。但对其它处理而言,这个表数据会多很多,而且多的那些似乎是无用数据。

请问一下,这二种方式,哪一种更优化?

谢谢!!

6 个解决方案

#1


看从哪个角度看了。。。
这两种方式俺都见过,如果希望优化存储管理,第二种更好一些,考虑运行效率,第一种会快一些;
还要看你的数据量,如果数据量很大,推荐第二种方式~

#2


这个数据量应该没什么事
干嘛不直接设置个时间字段,更新记录的时候把服务器时间写进去,查询的时候再取服务器的时候做比较就知道谁过时不过时了。

#3


第二种,而且你数据过期的操作可以用数据库的管理功能来自己维护。
这样你经常操作的info表负荷就比较小,执行效率也会快很多,特别是生成记录非常频繁,数据库中数据很多的时候

#4


谢谢大家,这么快就有这么多回复了。

我是在嵌入式设备上使用sqlite数据库,没有数据库的管理功能,只有依靠程序里的sql语句来操作。

数据量是日积月累,前期量会比较小,经过几年,我估计最终数据还是会比较多。当然,是指总的数据量比较多。如果是分成两个表的话,那就是info表的数据一定是在一定量以内,即使增加,也不会有暴发性的增加,而history的量会越来越大。

当然,如果是用一个数据表,则总量总有一天会比较惊人吧。

#5


俺的意思是如果是日常事务表,比如销售记录,量会很大,即使建了索引,也会影响查询效率的~这种情况下第二种会方便的多,如果过时记录查询需求不大,而且在查询连接较多的情况下,第二种方式是大大优于第一种的;
如果数据量小,比如员工信息,短期内第一种与第二种在效率上差别不大,但第二种做的操作更多,取数就没那么方便了;
所以还是要看你的数据特征,从长期考虑,有没有大量数据的存储的可能~

#6


谢谢大家!明白了!!

#1


看从哪个角度看了。。。
这两种方式俺都见过,如果希望优化存储管理,第二种更好一些,考虑运行效率,第一种会快一些;
还要看你的数据量,如果数据量很大,推荐第二种方式~

#2


这个数据量应该没什么事
干嘛不直接设置个时间字段,更新记录的时候把服务器时间写进去,查询的时候再取服务器的时候做比较就知道谁过时不过时了。

#3


第二种,而且你数据过期的操作可以用数据库的管理功能来自己维护。
这样你经常操作的info表负荷就比较小,执行效率也会快很多,特别是生成记录非常频繁,数据库中数据很多的时候

#4


谢谢大家,这么快就有这么多回复了。

我是在嵌入式设备上使用sqlite数据库,没有数据库的管理功能,只有依靠程序里的sql语句来操作。

数据量是日积月累,前期量会比较小,经过几年,我估计最终数据还是会比较多。当然,是指总的数据量比较多。如果是分成两个表的话,那就是info表的数据一定是在一定量以内,即使增加,也不会有暴发性的增加,而history的量会越来越大。

当然,如果是用一个数据表,则总量总有一天会比较惊人吧。

#5


俺的意思是如果是日常事务表,比如销售记录,量会很大,即使建了索引,也会影响查询效率的~这种情况下第二种会方便的多,如果过时记录查询需求不大,而且在查询连接较多的情况下,第二种方式是大大优于第一种的;
如果数据量小,比如员工信息,短期内第一种与第二种在效率上差别不大,但第二种做的操作更多,取数就没那么方便了;
所以还是要看你的数据特征,从长期考虑,有没有大量数据的存储的可能~

#6


谢谢大家!明白了!!