Mysql 跟踪数据库表更改

我正在尝试实现一种方法来跟踪名为

user

的表和另一个名为

report\u to

的表的更改，下面是它们的定义：

CREATE TABLE `user` 
(
    `agent_eid` int(11) NOT NULL,
    `agent_id` int(11) DEFAULT NULL,
    `agent_pipkin_id` int(11) DEFAULT NULL,
    `first_name` varchar(45) NOT NULL,
    `last_name` varchar(45) NOT NULL,
    `team_id` int(11) NOT NULL,
    `hire_date` date NOT NULL,
    `active` bit(1) NOT NULL,
    `agent_id_req` bit(1) NOT NULL,
    `agent_eid_req` bit(1) NOT NULL,
    `agent_pipkin_req` bit(1) NOT NULL,
    PRIMARY KEY (`agent_eid`),
    UNIQUE KEY `agent_eid_UNIQUE` (`agent_eid`),
    UNIQUE KEY `agent_id_UNIQUE` (`agent_id`),
    UNIQUE KEY `agent_pipkin_id_UNIQUE` (`agent_pipkin_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

CREATE TABLE `report_to` 
(
    `agent_eid` int(11) NOT NULL,
    `report_to_eid` int(11) NOT NULL,
    PRIMARY KEY (`agent_eid`),
    UNIQUE KEY `agent_eid_UNIQUE` (`agent_eid`),
    KEY `report_to_report_fk_idx` (`report_to_eid`),
    CONSTRAINT `report_to_agent_fk` FOREIGN KEY (`agent_eid`) REFERENCES `user` (`agent_eid`) ON DELETE NO ACTION ON UPDATE NO ACTION,
    CONSTRAINT `report_to_report_fk` FOREIGN KEY (`report_to_eid`) REFERENCES `user` (`agent_eid`) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8

需要跟踪的更改是

用户.team\u id

，

用户.active

和

报告对象.报告对象eid

。我目前实现的是一个表，它是通过

user

上的更新触发器填充的，用于跟踪团队的变化。该表定义如下：

CREATE TABLE `user_team_changes` 
(
   `agent_id` int(11) NOT NULL,
   `date_changed` date NOT NULL,
   `old_team_id` int(11) NOT NULL,
   `begin_date` date NOT NULL,
   PRIMARY KEY (`agent_id`,`date_changed`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8

这只适用于跟踪团队更改。我能够使用联接和联合来填充历史视图，该视图跟踪各个用户随时间而发生的变化。当我尝试对其他两种更改类型实施跟踪时，复杂性问题就出现了

我曾考虑过创建类似于跟踪团队更改的表的附加表，但我担心由于需要连接而导致的性能下降

我考虑过的另一种方法是创建一个类似于视图的表，该视图详细说明了当前用户状态（它将4个表中所有必要的用户数据连接在一起），然后在更新时插入一条记录，并添加一个有效的截止日期字段。我关心的是这会占用多少空间

我们将大量使用用户更改历史记录，因为我们几乎每天都会使用它运行YTD、MTD、PMTD和时间间隔报告

---

在我考虑的两个选项中，哪一个最适合我的情况？

您介绍的选项：

使用触发器填充事务日志表

在架构中包括一个新表，该表具有生效日期列，并通过插入新行跟踪更改

其中任何一个都可以。您可以向其他表添加日志触发器，而不会造成任何问题

这两种选择的区别是什么？第一个是简单的，一旦你调试了你的触发器

在我看来，第二种选择似乎会创建非规范化的冗余数据。这从来都不是好事。我会选择不那样做。通过明智地组合视图和生效日期列，可以创建可作为系统当前状态查看的历史记录表。要了解这一点，请看RT Snodgrass教授关于开发面向时间的应用程序的优秀著作。如果你有时间在这个项目上做一个优秀的工程（过度工程）工作，你可能会考虑这个方法。 您提到的数据量不会在任何现代服务器硬件平台上造成难以解决的性能问题。如果联接操作的速度确实变慢了，几乎可以肯定的是，添加适当的索引将完全修复它们，只要您声明所有的

日期

，

日期时间

，以及

时间戳

字段

非空

。（

NULL

值可能会打乱索引和搜索）

---

希望这能有所帮助。

当您的系统运行一年后，您的表中大约有多少行？我估计在

user

和

report\u中有apx 2000-2500，总共大约有7000个更改。