如何处理非 SQL 数据库上的数据方案更改？答案

【问题标题】：How to handle data scheme change on non-SQL databases?如何处理非 SQL 数据库上的数据方案更改？
【发布时间】：2011-06-26 10:18:27
【问题描述】：

根据我对非 SQL 数据库的经验，最大的问题之一是架构更改。在 SQL 数据库上添加或删除列操作简单，服务器在方案更改期间保证数据的稳定性。因此它可以在服务推进期间处理数据模式的变化。但是非 SQL 数据库（尤其是客观风格的系统）如何处理这些模式变化呢？有可靠的方法吗？

【问题讨论】：

这取决于所讨论的数据库，它们都是不同的。

标签： database nosql schema

【解决方案1】：

我同意 Skaffman 的观点，非 SQL 数据库涵盖了广泛的产品。每一个都倾向于提供不同级别的模式管理。

例如，键/值对数据库（如 Oracle Berkeley DB）是无模式的。放置在键/值对中的是一个不透明的结构，访问它的应用程序是已知的。在这种情况下，我经常看到应用程序在键/值对数据结构中实现一个字段来指示模式版本。应用程序在读取或写入记录时将根据它找到的模式版本采取适当的行动。这对某些应用程序可能是有利的，因为可以根据需要在给定的读/写操作上而不是批量应用架构更改。

另一个例子，XML 数据库，如Oracle Berkeley DB XML，以自我描述的 XML 格式存储数据。尽管集合中的大多数 XML 文档通常具有相同的模式，但对于给定的文档，模式当然也可以具有更多或更少的属性，甚至是可取的。这些非 SQL 数据库使用 XQuery 等查询语言，允许您查询数据的结构（属性）以及内容。

在另一个示例中，基于对象的数据存储（如 Berkeley DB 提供的 Data Persistence Layer API）可以支持作为底层 API 一部分的面向应用程序的模式演变，如 here 所述。

但是，即使使用 SQL 数据库，也只能从表面上轻松更改架构。应用程序通常必须知道任何模式更改才能正常运行。在 SQL 数据库中添加列会对倾向于执行“SELECT *”的应用程序产生不利影响，而重命名或删除列可能会对假定存在该列的应用程序产生不利影响。 SQL 数据库使模式更改“容易”，因为有一个 SQL 命令允许您添加、删除和重命名列。堆栈上的模式管理要求仍然需要仔细考虑并正确实施。

底线，通常模式演变要么由数据库引擎、应用程序或介入的 API 层管理。至于它有多“容易”，很大程度上取决于它上面的应用程序层以及它们如何受到架构更改的影响。

如果您可以更具体地说明您要解决的问题，我们或许可以提供更具体的建议。具体来说，您使用的是哪个数据库，您如何看待架构的演变？

问候，

戴夫

【讨论】：

谢谢。我关心 SQL 数据库引擎功能，例如有助于数据完整性的约束。借助这些功能，即使应用程序尝试错误操作，数据本身也可以整合。这很重要，因为多种客户端应同时操作以进行单一数据存储。如果在数据库之外获得数据完整性，系统很难扩展，这将限制它的应用。约束层可以和数据引擎分离，但它需要做一种可以处理所有类型客户端的数据网关...
很难想象数据库引擎会抱怨“禁止，因为该字段旨在从其他实体引用”这样的情况。关于从实体中删除字段。
同样，这取决于相关数据库引擎的实现。例如，虽然 Berkeley DB 的核心是一个键/值对数据库，但至少有两种方法可以处理约束：a) 使用允许您实现 SQL 约束和模式的 SQL API，或 b) 使用直接在此处记录的键/值 API 中的外键引用函数：bit.ly/ebGUU0。无论哪种情况，Berkeley DB 引擎都会强制执行您定义的约束。