TL;DR 在一个结构非常糟糕的数据库(有很多列重复、没有相互关系和重复数据)之间迁移大量数据到另一个高度组织和关系结构的最佳方法是什么？ - 抱歉读了这么久!
我最近接手了一份非常复杂的工作。它正在重写整个公司的基于 Web 的 IT 平台。恐怕我不能提供太多细节，因为我们不能让老开发人员知道(他有一把隐喻的枪指着公司的脑袋，因为他是唯一一个知道如何做发票生成等关键事情的人，并且要求越来越多的钱)。
主要问题是整个网络平台(所有员工和所有客户都使用)是由一个技术水平低于业余水平的人编写的。它由约 300 个单独的代码文件组成。没有模板库 - 它全部硬编码到每个文件中。没有逻辑的数据库结构——它实际上是在他进行的过程中组成的。没有安全保障——这令人震惊。无论如何，我们将在大约 3 个月的时间内重写整个平台。
但是老板说，在上线的那天早上，任何地方都不会丢失任何客户数据。必须直接复制整个数据库内容。数据库的结构目前非常糟糕，几乎无法使用，但本周我们将(尝试!)编写一些脚本，将其迁移到我们新的、高度相关的结构中，这种结构更加合乎逻辑。 问题是，最好的方法是什么？
一个例子是地址。在旧数据库中，大约 12 个表(总共 44 个......)中使用了地址。在我们的中，我们有一个 addresses 表，它将被其他表(例如 address_id)交叉引用以保持干净。主要问题是在他的大约一半的表中，地址存储为line1、line2、town、city 等，这很好，但在另一半他只有一个 address 字段来存储整个内容!
第二个例子是日期——在一些表中他有秒-since-Epoch 日期，在其他 MySQL NOW() 日期中，在其他表中他将其存储在每行 6 列中 - year, month, day, hour, minute, second - 哎哟...
尝试解决这个问题的好方法是什么？ 我们应该查看 我们的 表并找出我们需要将 他的 数据从哪里提取到我们的表中，还是应该反过来看 他的 表并找出他的数据需要进入我们的哪里？
从编程的角度来看，我们应该如何解决这个问题？很多数据需要动态格式化(例如日期)，所以我们考虑一次提取一行数据，格式化它正确，然后将其重新插入到我们脚本中的正确位置。
查询的速度和效率对我们来说不是问题，因为我们只需要在本地机器上运行一次(测试后)。当 SQL 转储时，他的数据库目前约为 800MB，但其中很多都是他无用的测试数据，或者完全没有必要。
关于解决这个问题的最佳方法有什么想法吗？作为引用，我们的系统将用 PHP 重新编写，因此任何基于 PHP 的建议都会很好。该数据库目前(并将仍然)在 MySQL 中。
最佳答案
这里没有解决方案。没有魔法。只是简单的努力工作。
您有了自己的新模型，完成这项工作的唯一方法是转到每个表，并在纸上、白板上等以逻辑方式将它们单独转换为新模型。
您要处理的不仅仅是简单的格式问题。您还需要处理数据重复问题。如果您有 12 个带地址的表，但只有 1 个客户端，哪个地址获胜？
仅这一决定就可以简化很多处理(例如，也许您可以忽略其他地址，而不是链接到主客户记录的一个受祝福的地址)。
这就把你带到了最后一个问题。转换期间“不丢失任何数据”。
根据“不丢失任何数据”的含义，这很可能从第一天起就无法启动。例如，如果您要丢弃地址，数据就会丢失。当然，每个组件“都有一个地址”，但不一定是它们之前的地址。以前它们可能完全相同，但也可能不相同。会很乱。
完成映射和其他过程后，使用大多数语言编写代码都非常简单。脚本语言对此很有效。您可以“按原样”将每个表批量加载到新数据库中，并编写存储过程来进行转换。无论你熟悉什么。您的转换可能需要几个步骤，并且大部分代码可能只是为了促进转换而“一次性”完成。
这会很乏味。这些东西一直都是。细节太多了。这是一个可怕的系统的所有原因都是转换将是可怕的原因。如果您没有足够的时间来完成它，请不要感到惊讶。
最后，如果您有大量数据，如果您无法在业务停机期间(无论是周末还是夜间)执行切换，则可能需要处理一些时间限制。如果您在更新数据的过程中执行此操作，那将是另一回事。如果可能的话，我强烈建议不要这样做。
关于mysql - 将数据库内容从一种非常糟糕的结构迁移到一种非常合乎逻辑的结构的最佳实践？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6973452/