如何处理非SQL数据库上的数据方案更改？ [英] How to handle data scheme change on non-SQL databases?

问题描述

正如我对非SQL数据库的经验，最大的问题之一是模式更改。在SQL数据库上添加或删除列很容易操作，服务器保证在方案更改期间的数据稳定性。因此，它可以在服务提前期间处理数据模式更改。但是如何非SQL数据库（特别是客观风格的系统）处理这些模式的变化？是否有可靠的方法？

As I experienced about non-SQL databases, one of biggest problem was schema change. Adding or removing columns on SQL database is easy operation and server guarantees data stability during scheme change. So it can handle data schema changes during service advancing. But how to non-SQL databases (especially objective style systems) handle those schema change? Is there reliable method?

推荐答案

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

I agree with Skaffman, non-SQL databases covers a broad spectrum of products. Each one tends to provide different levels of schema management.

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

For example, key/value pair databases, like Oracle Berkeley DB are schema-free. What is placed in the key/value pair is an opaque structure, which is known to the applications that access it. In this case, I've often seen applications implement a field within the key/value pair data structure to indicate the schema version. The application, when reading or writing the record will take the appropriate action based on the schema version it finds. This can be advantageous for some applications, since schema changes can be applied as required on a given read/write operation rather than in bulk.

又如，XML数据库，例如 Oracle Berkeley DB XML 以XML格式存储数据，这是自描述。虽然对于集合中的大多数XML文档而言，具有相同的模式是常见的，但是对于给定文档，模式具有额外的或更少的属性是可能的，甚至是期望的。这些非SQL数据库使用像XQuery这样的查询语言，允许您查询数据的结构（属性）以及内容。

Another example, XML databases, like Oracle Berkeley DB XML store data in XML format which is self describing. Although it's common for most XML documents within a collection to have the same schema, it's certainly possible and even desirable for the schema to have additional or fewer attributes for a given document(s). These non-SQL databases employ query languages like XQuery, that allow you to query the structure (attributes) of the data as well as the content.

在另一个示例中，基于对象的数据存储，如数据与Berkeley DB一起提供的持久层API 可以支持面向应用程序的模式演化，作为底层API的一部分，如 here 。

In yet another example, object-based data stores, like the Data Persistence Layer API provided with Berkeley DB can support application-directed schema evolution as part of the underlying API, as described here.

但是，即使使用SQL数据库，只需要更改表面上的模式即可。应用程序通常必须知道任何模式更改才能正常操作。在SQL数据库中添加列可能会对倾向于执行SELECT *的应用程序产生负面影响，而重命名或删除列会对假定该列存在的应用程序产生负面影响。 SQL数据库使模式更改简单，意思是有一个SQL命令，允许您添加，删除和重命名列。堆栈上的模式管理需求仍然需要被思考和正确实现。

However, even with SQL databases it's only easy to change the schema on the surface. The application usually has to be made aware of any schema changes in order to operate properly. Adding a column in a SQL database can adversely affect applications that tend to do "SELECT *", while renaming or removing a column can adversely affect applications that assumed the existence of that column. SQL databases make schema change "easy" in the sense that there's a SQL command that allows you to add, drop and rename columns. The schema management requirements up the stack still need to be thought through and implemented properly.

底线，典型的模式演进由数据库引擎，应用程序或中间API层管理。至于如何容易，它取决于它上面的应用程序层，以及它们如何受到模式更改的影响。

Bottom line, typically schema evolution is either managed by the database engine, the application or the intervening API layer. As for how "easy" it is, depends a lot on the application layers above it and how they are affected by the schema change.

如果您可以更具体地了解您要解决的问题，我们可能会提供更具体的建议。

If you can be more specific about the problem that you're trying to solve we might be able to provide more specific suggestions. In particular, which database are you using and how do you see your schema evolving?

请注意，

Dave

这篇关于如何处理非SQL数据库上的数据方案更改？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！