还有哪些其他类型的数据库系统。我最近遇到过以非关系方式处理数据的ouchDB。这让我开始思考其他人正在使用的其他模型。

因此，我想知道还有哪些其他类型的数据模型。 (我不是在寻找任何细节，只是想看看其他人如何处理数据存储，我的兴趣纯粹是学术上的)

我已经知道的是：

• RDBMS(mysql，postgres等。)
• 基于文档的方法(couchDB，Lotus Notes)
• 键/值对(BerkeleyDB)

解决方案

回答

db4o

从"关于"页面引用：

db4o is the open source object database that enables Java and .NET developers to store and retrieve any application object with only one line of code, eliminating the need to predefine or maintain a separate, rigid data model.

回答

亚马逊的SimpleDB并非是非关系的吗？

回答

正如Eric所提到的，db4o是一个面向对象的数据库管理系统(OODBMS)。

回答

有基于对象的数据库(例如，Gemstore)。 Google的Big-Table和Amason的Simple Storage我不确定我们如何进行分类，但是它们都是基于map-reduce的。

回答

较旧的非关系型数据库：

网络数据库

分层数据库

当关系变得可行时，两者大多都过时了。

回答

面向列的数据库也有点不同。他们中的许多人确实支持标准的关系数据库SQL。这些通常用于数据仓库类型的应用程序。

回答

我们一直在研究的非关系型面向文档的数据库是Apache CouchDB。

Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. Among other features, it provides robust, incremental replication with bi-directional conflict detection and resolution, and is queryable and indexable using a table-oriented view engine with JavaScript acting as the default view definition language.

我们的兴趣是提供一种不受形状变化影响的分布式访问用户首选项存储，我们可以将其从Java序列化首选项对象，并使用基于XULRunner的客户端应用程序中的Javascript轻松访问这些对象。

回答

语义Web也是非关系数据存储范例。没有关系，所有元数据都以与数据相同的方式存储，并且每个实体都可能具有其自己独特的属性集。实现RDF(一种语义Web标准)的开源项目包括Jena和Sesame。

回答

文件系统，语义Web，XML，对象数据库，CODASYL以及许多其他类型都属于此类。

那四个差不多。

回答

也有所谓的"反向索引"或者"反向列表"数据库。 Software AG的Adabas产品就是一个例子。与分层方法一样，由于遗留因素或者某些情况下(通常是高端事务性应用程序)的性能优势，这些数据库仍继续在大型公司或者大学环境中使用。

回答

有BASE系统(基本可用，软状态，最终一致)，它们可以与包含大量数据的简单数据模型一起很好地工作。 Google的BigTable，Dojo的Persevere，亚马逊的Dynamo，Facebook的Cassandra就是其中的一些例子。

见链接

回答

启发性相关数据库是一个新的革命性非关系数据库。关联数据库管理系统(CDBMS)是独立于数据模型的，旨在在分析系统环境中有效处理计划外的临时查询。与关系数据库管理系统或者面向列的数据库不同，关联数据库使用基于值的存储(VBS)架构，其中每个唯一数据值仅存储一次，并且自动生成的索引系统维护所有值的上下文(数据为100％索引)。使用自然语言而不是SQL(NoSQL)执行查询。

了解更多信息，请访问：www.datainnovationsgroup.com

回答

我想详细介绍Bill Karwin关于语义网和三元组存储的答案，因为这是我目前正在研究的内容，对此我有话要说。

三重存储背后的想法是存储一个基于图形的数据库，其数据模型源于RDF。使用RDF，我们可以描述节点和节点之间的关联(即边)。数据按三重组织：

start node ----relation----> end node

(在RDF语音中：subject --predicate-> object)。使用这个非常简单的数据模型，只要我们为节点和关系赋予含义，任何数据网络都可以通过添加越来越多的三元组来表示。

RDF非常笼统，它是一个基于图的数据模型，非常适合搜索条件，以主题，谓词或者宾客的特定组合(所有组合)查找所有三元组。最终，通过称为SPARQL的查询语言，我们还可以执行更复杂的查询，该操作归结为图形的同构图搜索，无论是在拓扑结构上还是在节点边缘含义方面(我们都会看到这一点)一会儿)。 SPARQL仅允许我们进行SELECT(和类似)查询。没有删除，没有插入，没有更新。我们查询的信息(例如我们感兴趣的特定节点)被映射到一个表中，这就是我们从查询中获得的信息。

现在，拓扑本身并不意味着什么。为此，发明了一种模式语言。实际上，在某些情况下，将多个语言称为模式语言是非常有限的。今天最著名和使用的是RDF-Schema，OWL(精简版和完整版)，它们早于过时的DAML + OIL。这些语言的目的是沸腾东西，为节点(通过授予它们一种类型，也称为三元组)和关系(边)赋予含义。另外，我们可以定义这些关系的"范围"和"域"，或者用不同的方式表示开始节点是什么类型，结束节点是什么类型：例如，我们可以说属性" numberOfWheels"只能应用将Vehicle类型的节点连接到非零整数值。

ns:MyFiat --rdf:type--> ns:Vehicle
 ns:MyFiat --ns:numberOfWheels-> 4

现在，我们可以在两个方向上使用这些本体：验证和推断。今天的验证并不是那么花哨，但是我已经看到了使用实例。推理是当今最酷的事情，因为它允许推理。推理基本上采用包含一组三元组的RDF图，进行本体处理，将它们混合到包含"推理机"的三元组数据库中，就像魔术一样，推理机根据本体描述来发明三元组。示例：假设我们只是将此信息存储在数据库中

ns:MyFiat --ns:numberOfWheels--> 4

没别的。没有为此节点指定类型，但是推理引擎会自动添加一个三元组，表示

ns:MyFiat --rdf:type--> ns:Vehicle

因为我们在本体中说过，只能使用numberOfWheels属性来描述Vehicle类型的对象。

相反，我们可以使用推理引擎根据本体验证数据，从而拒绝不兼容的数据(类似于XML的XML-Schema)。在这种情况下，我们将需要两个三元组才能使数据成功地被三元组接受。

三重存储的其他特征是"公式"和"上下文感知"存储。公式是描述假设内容的语句(通常是三元主题谓词对象)。我从没使用过公式，所以我不会进一步介绍我不知道的东西。上下文感知基本上是子图：存储三元组的问题是我们无话可说这些三元组的来源。假设我们有两个经销商描述了一个组件的相同价格。一个说价格为5.99，另一个说价格为4.99. 如果我们仅将两个三元组都存储到数据库中，那么现在我们对谁说了每条信息一无所知。有两种方法可以解决此问题。

一种是具体化。标准化意味着我们存储其他三元组以描述另一个三元组。这很浪费，并且使生活变得地狱，因为我们必须对存储的每个三元组进行验证。另一种选择是上下文感知。具有上下文感知存储就像能够将一堆三元组装到带有标签(上下文标识符)的容器中一样。现在，我们可以将此标识符用作其他语句的主题，从而在单个操作中描述一堆三元组。