Database 如何在非SQL数据库上处理数据方案更改？

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

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

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

另一个例子是XML数据库，比如以自描述的XML格式存储数据。虽然集合中的大多数XML文档都具有相同的模式是常见的，但对于给定文档，模式具有附加或更少的属性当然是可能的，甚至是可取的。这些非SQL数据库使用诸如XQuery之类的查询语言，允许您查询数据的结构（属性）和内容

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

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

总之，模式演化通常由数据库引擎、应用程序或中间的API层管理。至于它有多“简单”，很大程度上取决于它上面的应用程序层以及它们如何受到模式更改的影响

如果您能更具体地说明您试图解决的问题，我们可能会提供更具体的建议。特别是，您使用的是哪一个数据库，以及您如何看待模式的发展

问候,

---

Dave

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