Sql 数据库中的上次修改日期与上次修改日期是否相同？

我正在设计我的数据库，以便可以进行增量备份。我认为应该有一个每周的cron作业，将数据转储到只读tar.bz2中，并且可以轻松转储我的大部分数据，因为它有一个修改过的日期或是仅插入的。然而，也有一些东西，比如保存密码和签名的user_profile。我如何知道何时需要转储/更新？我应该使用一个名为is_dirty的位，还是应该修改日期？每种方法的优缺点是什么

---

目前我正在使用sqlite，我正在切换到tsql，如果有问题，我可能会切换到mysql，这取决于我的主机提供程序上次修改是否可以正常工作，我建议您的逻辑导出保留其自己关于上次备份内容的数据，并且不要使用is_脏标志。让您的数据设计与您的数据相关，让您的逻辑导出跟踪上次备份的内容。在所有这些之前，您是否彻底查找过已经编写的备份系统？（为什么要重新发明轮子？）

此外，进一步考虑，任何标志列通常都没有很好的索引，因此对该列的查询可能是一个真正的阻力。除非使用位图索引，否则它有自己的注意事项和需要注意的事项

---

我总是将我所有的表设计成一个条目日期字段（支持触发器）和一个mod日期字段（同样支持触发器）。

我建议使用

last\u modified

，因为这个时间戳不仅对备份过程有效，而且这样的字段通常是有用的跟踪数据。与

is_dirty

标志相比，了解字段何时更新将有助于调试生产问题（了解用户配置文件何时更新，并将其与用户投诉时间关联）和验证db更新的增强功能。

触发器是什么意思？代码中的逻辑触发器还是数据库中的触发器？（我听说过sqlite触发器，但我不知道它们是什么）。我不是在写备份工具。这样我就不会在每次备份数据时都被迫转储整个表。是的，触发器是在您选择的数据库中运行的存储过程。大多数（但不是全部）数据库都以某种形式支持它们。在这种情况下，您将编写一个触发器，在插入或更新时（分别）用当前时间自动填充输入日期和修改日期。出于各种原因，您不应该依赖应用程序代码来完成这项工作，但最重要的是跨客户端的时间同步。应用增量数据库备份是一件乏味的事情，如果您错过了一步，这将是一件非常痛苦的事。我不会为SQL Server或MySQL上的方法而烦恼——这就是事务日志的用途，因此您不需要将其合并到数据模型中。创建自己的增量备份过程不仅繁琐，而且从长远来看非常容易出错。通常会发现应用程序级备份随着时间的推移不会更新以反映数据库中的新表。或者-使用在Database上执行转换时未更新的时间戳，等等。仅供参考。。。