mysql - 最佳实践：截断并重新创建关联表条目或每天更新它们？

Question

我们正在将定制的中间件/API 从 Python 2 重构到 3。该软件负责在许多不同平台（如 ebay、amazon、 shopware) 通过从我们的 ERP 软件导出的数据。该软件在虚拟化的 Ubuntu 服务器上运行，并拥有自己的 MariaDB 数据库，每天运行。我们正在接触负责处理 ERP 软件数据导出的脚本，现在正在讨论如何处理我们的某些关联表的“最佳”方法。

一个例子：有两个表用于处理产品到图像的关系，“global_images”（~140k 行）和“article_image_mapping”（~250k 行）。'global_images' 包含图像文件名和排序顺序，并通过其在 'article_image_mapping' 中的 ID 以及相应的产品 ID 进行引用。例如，每当产品获得新图像时，我们必须确保所有条目都是最新的。需要删除旧的“article_image_mapping”行，需要引用新的行，我们还必须更新与产品 ID 相关的所有条目的排序顺序。

这个过程当然没什么大不了的，类似于在 MySQL 中更新关联表，但我们在想：是什么让我们不能简单地截断两个表并每天重新创建它们？这将使我们的代码更简洁、更简单，只要产品 ID 保持不变，其他引用就可以随意更改。此外，我们不会用数十万个 ON DUPLICATE KEY UPDATE 查询来膨胀 AI 索引，即使这可能可以忽略不计。

不知何故，这感觉不那么优雅。我们还必须确保我们的异常处理达到标准，因为如果没有图像产品映射，其他脚本将无法运行。

标签： mysqlsqldatabasemariadb

Answer 1

如果您的重点是正确的数据，那么每天重建整个表是一个非常合理的解决方案。我不确定您的确切过程是什么，但如果它很容易符合您重建和资源的时间限制，那么您就知道数据就是您想要的。

主要优点是数据简单。使用一种方法，update您必须处理insert//逻辑。在处理边缘情况时，可能不清楚您需要做什么。updatedelete

主要缺点是您最终可能会重写历史记录。如果对影响历史的源数据进行了更改，那么事情可能会变得混乱。这可能是报告的问题。

我经常设计每天都在重建的系统。. . 但有一个警告。它们位于云服务器上，存储基本上是免费的，我们可以存档旧副本以查看过去“真正发生了什么”。