数据库模式迁移在生产环境中是否存在问题？

在关于NoSQL和SQL数据库的讨论中，我有时听到公司更喜欢使用无模式的NoSQL数据库，因为将模式迁移到新版本是有问题的。但这在升级时真的是一个大问题吗？关系数据库是否对此类操作有害？

我在MongoDB博客上阅读了该博客文章：为什么使用Schemaless？

仅仅因为您的NoSql数据库没有传统意义上的架构，并不意味着您在更改逻辑架构时就无需对其进行处理。在使用MongoDb的典型应用程序中，您的代码很可能希望json对象的某些字段以某些方式运行。如果更改行为，则可能是要更新数据库中已经存在的数据。现在，使用传统的RDBMS，这已在很大程度上解决了问题-您只需要更改基础表即可。但是，有了这些新型的NoSQL数据库，您就有了决定-是否编写脚本来修改和更新所有对象？还是添加代码以在不同版本之间进行转换？如果是这样，您支持v1对象多长时间？永远？直到v3？

我还要补充一点，如果您有一个不错的更新过程，无论RDBMS是什么，MongoDb博客文章中使用的示例都会有点简单，并且很容易处理。添加字段很少会带来伤害。这是当你决定你的分裂Name场成FirstName和LastName事情变得令人兴奋。

但这在升级时真的是一个大问题吗？

有可能。

一些组织-杂乱无章，并且在架构迁移方面做得非常糟糕。

1. “迁移周末”。停止服务器。备份并导出所有数据。构建新的架构（通常通过修改现有架构）。重新加载数据或尝试就地重组。

2. “连续调整”。在SQL允许的范围内更改表。无需跟踪ALTER的执行顺序。无法返回到先前的架构版本。必要时，从现有表中创建新表，希望调整所有应用程序以使用新表。但是-缺乏良好的质量检查-将旧表留在原地以防万一。

3. “完全恐慌”。只需阻止架构修改即可。大发臭。声称风险过高。阻止所有朝这个方向的努力。将模式作为人质，直到被迫采取更明智的方法。

关系数据库是否对此类操作有害？

任何模式都很难迁移。

最大的问题不是技术问题。

这是语义上的。

更改架构的一个原则原因是先前的架构与问题域的匹配程度不是很高。由于语义已更改，因此数据库（和应用程序）需要更改。有时，这些巨大的变化需要重新考虑应用程序处理数据的方式。

修改数据库的语义可能非常困难。

人们所做的而不是更改架构只是滥用物理架构。他们开始将错误的数据加载到现有字段中，因为它们可以这样做。“评论”字段突然开始具有重要的客户管理信息，后跟“ //”和真实评论。这就变得需要数据“字段1-字段2 //注释”。用户拥有一个电子表格，该电子表格可从注释字段中提取此其他数据，因为“真正的”应用程序软件具有难以更改的架构，IT拒绝更改它。

我们升级生产数据库，添加表和（可为空）列没有问题。该应用程序的早期版本可以与升级后的数据库配合使用，只是它们没有引用新内容。我们避免删除表或列，或更改现有数据的存储方式，尽管在必要时我们会生成适当的转换脚本。无论您的数据库是否具有已声明的类型安全模式，数据结构的更改都需要数据转换和应用程序升级才能与新结构交互。

这取决于。

首先，如果您有一个跨多个计算机的大型数据库，那么所有事情（而不仅仅是数据库更新）都会很麻烦。（无论您提前计划了多少）。

其次，更新数据库不仅是数据库工作，而且还取决于数据库所在的更大系统。这也包括数据库部署（许多数据库服务器，多个数据中心，主从设置等）。

通过对系统组件进行架构设计，使它们都具有对DB模式更改事件的某种“认知”，可以减轻这种痛苦。这意味着整个系统应该容忍架构更改，并且可以以“理智”的方式对其进行响应。

您可以签出Facebook开发的用于处理MySQL模式更新的实用程序。

此外，还有一些标准的最佳实践，例如将您的母版设为只读，对从属版或开发副本进行更改等。

无论如何，必须拥有完整的备份和广泛的测试套件。只有这样，您才能自信，安全地进行任何更改。