跟踪数据库的变化对很多人来说肯定是一个大问题，但似乎大牌有软件。
我的问题是对于一个有 10 个表，每个 <10 列的小型 SQL 数据库，使用连接创建一个“主”连接表：通过添加行（有很多重复信息）每年更新几次是否有缺点然后使用 MAX id (PK) 以表格形式（摘自“master”）生成并在网站上发布最新数据？这与更新记录相比，我将在特定时刻丢失有关值的信息。
教师联系信息的典型行有 fName、lName、schoolName、[地址和电话信息]；曲目或试听信息：年份、乐器、作品、作曲家、出版商/版本。
其他人询问了跟踪数据库更改，但最近只有一个，并且没有很多投票/详细信息：如何跟踪数据库表中的数据更改 保留数据修订的历史记录 - 最佳实践？ 如何跟踪数据库表中的数据更改
这个轻量级的解决方案看起来很有希望，但我不知道它没有得到投票是因为它没有帮助，还是因为人们不感兴趣。如何跟踪表中数据的更改？
如果需要更多背景知识：我是一名音乐老师（即业余程序员），为我们的组织维护一个 Joomla 网站。我正在使用一个名为 Sourcerer 的 Joomla 插件来创建动态内容（PHP/SQL 到 Joomla 数据库），以便更轻松地传达更改（日期、人员、规则、曲目等）。多年来，这是通过静态页面完成的（和纸质手册）需要几天时间才能更新。
但是，我也希望能够回顾并查看特定时间的数据库状态：谁教在哪里，列出了哪些试听作品等，就像我们可以使用纸质版本一样。注意：我不跟踪 HTML 更改，只跟踪从数据库提供的信息。
谢谢你的帮助！（我已经关注 SO 多年，但这是我的第一个问题。）
我现在用来生成“主连接表”的代码。对于我的新行，我会将其修改为“插入”，并通过 Sourcerer 从中查询以在线发布信息。
CREATE TABLE 011people_to_schools_junction
AS (
SELECT *
FROM (
SELECT a.peopleID, a.districtID, a.firstName, a.lastName, a.statusID, c.schoolName
FROM 01People a
INNER JOIN (
SELECT districtID, MAX(peopleID) peopleID
FROM 01People
GROUP BY districtID
) b
ON a.districtID = b.districtID
AND a.peopleID = b.peopleID
INNER JOIN (
SELECT schoolID, MAX(peopleID) peopleID
FROM 01people_to_schools_junction ab
GROUP BY schoolID
) z
ON z.peopleID = a.peopleID
LEFT JOIN 01Schools c
ON c.schoolID = z.schoolID
WHERE z.schoolID IS NOT NULL
OR z.peopleID IS NOT NULL
ORDER BY c.schoolName
) t1
);
#Add a primary key as the first column
ALTER TABLE 011people_to_schools_junction
ADD COLUMN 011people_to_schoolsID INT NOT NULL AUTO_INCREMENT FIRST,
ADD PRIMARY KEY (011people_to_schoolsID);
要按顺序回答您的问题：
有什么缺点吗？
当然，这与性能有关。如果每年增加一百万条记录，会影响性能；并占用磁盘空间。
链接问题中的建议在哪里不好或不受欢迎？
问题和答案都很好；但正确的答案取决于您的具体用例：您是否出于法律原因这样做，您希望能够以多快的速度访问数据，您拥有多少数据和更新，您希望历史功能在没有更改的情况下持续多少...只有当它满足您的用例时，您才会投票。
根据经验，历史记录应该放在不同的表中，这将提供以下几个优点：
为了选择是有一个历史表还是多个（每个备份表一个）取决于您计划如何检索数据以及您想用它做什么：
如果您镜像每个表并添加时间戳和用户 ID，则您的代码几乎不需要修改；但是你最终会得到两倍的表，并且任何结构更改都需要在历史表上复制；
如果您构建一个带有时间戳、用户 ID、表名和记录的 json 表示的单个历史表，您将更轻松地构建它，而为了检索它，您应该使用每行一个对象访问数据，即使用 Joomla 的 dbo getObjectList()，那么对象将与您存储在历史表中的格式相同，并且那里的更改将相当容易。但是跨特定表/字段查询更改会困难得多。
请记住，如果您无法正确检索数据，那么拥有数据将毫无用处。
既然你提到每年推送几次网站，查询的开销应该不是问题（如果你每月更新，等待 5 分钟可能不是问题）。
您应该根据这些数据的其他用途寻求最佳解决方案：为了对任何人有用，您必须实施一个系统来检索历史数据。如果 phpmyadmin 就足够了，那就不用再看了。
我希望这吓到你了。无论哪种方式，这都是一项艰巨的工作。
如果您只是希望能够查找旧数据，则可以改为存储不时生成的标记/输出的副本，并将其保存到网络服务器上的不同文件夹中。这将需要几分钟的时间来设置，并且非常可靠。
当然，编写代码更有趣。但你真的确定你需要它吗？您可以保留数据库转储，以防有一天您改变主意。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句