我们能否指出替代的数据存储工具，并给出充分的理由来使用它们而不是陈旧的关系数据库？在我看来，大多数应用程序很少使用SQL的全部功能-看看如何构建不依赖SQL的应用程序会很有趣。

解决方案

回答

文件系统非常适合存储二进制数据，在关系型数据库中，它从来都无法出色地工作。

回答

G'day，

我能想到的一种情况是，当我们建模的数据无法轻松地在关系数据库中表示时。

曾经有这样一个例子的是移动电话运营商用来监视和控制移动电话网络基站的数据库。

在几乎所有这些情况下，都使用了OO DB，无论是商业产品还是允许对象层次结构的自卷式系统。

我曾为一家大型公司开发3G监视应用程序，该公司将保持匿名，但其徽标是红酒色(-：，并且他们使用此类OO DB来跟踪内部单个单元的所有各种属性。网络。

使用通常通常完全不使用SQL的专有技术来查询此类数据库。

HTH。

干杯，

抢

回答

文件系统中的纯文本文件

• 创建和编辑非常简单
• 用户易于使用简单的工具(例如，文本编辑器，grep等)进行操作
• 有效存储二进制文件

磁盘上的XML或者JSON文件

• 如上所述，但是具有更多的验证结构的能力。

电子表格/ CSV文件

• 商业用户易于理解的模型

Subversion(或者类似的基于磁盘的版本控制系统)

• 很好地支持数据版本控制

Berkeley DB(基本上是基于磁盘的哈希表)

• 从概念上讲非常简单(只是未键入的键/值)
• 蛮快
• 没有管理开销
• 支持我相信的交易

亚马逊的简单数据库

• 我相信很像伯克利分校，但是托管

Google的App Engine数据存储区

• 托管且高度可扩展
• 每个文档的键值存储(即灵活的数据模型)

CouchDB

• 文件重点
• 简单存储半结构化/基于文档的数据

本地语言集合(存储在内存中或者在磁盘上序列化)

• 非常紧密的语言集成

自定义(手写)存储引擎

• 在某些用例中可能具有很高的性能

我不能声称对它们了解太多，但是我们可能还希望研究对象数据库系统。

回答

对象数据库不是关系数据库。如果我们只想在数据库中填充一些对象，它们将非常方便。它们还支持版本控制和修改数据库中已经存在的对象的类。 db4o是第一个想到的。

回答

仅使用存储在文件系统中的文件，我们可以走很长一段路。 RDBMS在处理斑点方面变得越来越好，但这是处理图像数据等的自然方法，尤其是在查询简单(枚举和选择单个项目)的情况下。

层次结构数据结构是RDBMS不太适合的其他东西，我猜想地理空间数据和3D模型都不容易使用。

诸如Amazon S3之类的服务提供了不支持SQL的更简单的存储模型(键-值)。可伸缩性是关键。

Excel文件也很有用，特别是如果用户需要能够在熟悉的环境中操作数据并构建完整的应用程序来做到这一点不可行时，尤其如此。

回答

尝试使用Prevayler：
http://www.prevayler.org/wiki/
Prevayler替代了RDBMS。在网站上有更多信息。

回答

有很多存储数据的方法，甚至"关系数据库"涵盖了一系列简单代码库中的替代方案，这些代码可操纵本地文件，就好像它是基于单个用户的关系数据库一样，通过文件可以处理多个用户的大量基于严重"服务器"系统的系统。

我们使用XML文件很多，我们可以获得结构良好的数据，用于查询的漂亮工具，如果有的话，也可以进行编辑，这些都是人类可读的，因此我们不必担心db引擎的工作(或者db的工作情况)引擎)。这对于本质上是只读的东西(在我们的情况中，通常不是从其他地方的数据库生成的东西)以及单用户系统中都非常有效，在单用户系统中，我们可以根据需要加载数据并将其保存出来，但是却为如果要多用户编辑至少一个文件，则会出现问题。

对于我们而言，我们或者使用将执行SQL的功能(MS提供了一系列从.DLL运行的工具，就可以将单个用户的操作一直贯穿到企业服务器，而且它们都使用相同的SQL(有较低的限制))，否则我们将使用XML作为格式，因为(对我们而言)冗长性很少成为问题。

我们目前无需在应用程序中处理二进制数据，因此不会出现此问题。

墨菲

回答

马特·谢泼德(Matt Sheppard)的回答很好(修改过)，但是在考虑主轴时，我会考虑以下因素：

• 结构：它显然会分解成碎片，还是在权衡取舍？
• 用法：将如何分析/检索/收集数据？
• 生命周期：数据有用多长时间？
• 大小：有多少数据？

与RDBMSes相比，CSV文件的一个特殊优势是它们可以很容易地压缩并移动到几乎任何其他机器上。我们进行大数据传输，而且一切都非常简单，我们只使用一个大CSV文件，并且可以使用rsync之类的工具轻松编写脚本。为了减少大CSV文件上的重复，可以使用YAML之类的东西。我不确定是否会存储JSON或者XML之类的东西，除非我们有重要的关系要求。

至于未提及的替代方案，请不要忽视Hadoop，后者是MapReduce的开源实现。如果我们需要分析大量结构松散的数据，并且希望只添加10台以上的计算机来处理数据，那么这应该可以很好地工作。

例如，我开始尝试分析性能，该性能实际上是在大约20台计算机上记录的不同功能的所有计时编号。在尝试将所有内容都保留在RDBMS中之后，我意识到，聚合之后，我真的不需要再次查询数据。而且，它对我来说仅是汇总格式有用。因此，我保留了日志文件，对其进行压缩，然后将聚合的数据保留在数据库中。

请注意，我更习惯于考虑"大"尺寸。

回答

在某些情况下(例如，金融市场数据和过程控制)，我们可能需要使用实时数据库而不是RDBMS。参见维基链接

回答

如果应用程序数据本质上是面向键/值的并且是分层的，则可能需要考虑使用LDAP服务器代替传统的SQL数据库。

回答

不使用关系数据库的一个很好的理由是，当我们拥有大量数据集并且想要对数据进行大规模并行和分布式处理时。 Google网络索引将是这种情况的完美示例。

Hadoop还具有称为Hadoop分布式文件系统的Google文件系统的实现。

回答

BTree文件通常比关系数据库快得多。 SQLite在其中包含一个BTree库，该库处于公共域中(就像在真正的"公共域"中一样，没有宽松地使用该术语)。

坦率地说，如果我想要一个多用户系统，我需要说服很多人不要使用像样的服务器关系数据库。

回答

Custom (hand-written) storage engine / Potentially very high performance in required uses cases

http://www.hdfgroup.org/

如果我们有大量数据集，则可以使用HDF(分层数据格式)，而不是自己滚动数据集。

http://en.wikipedia.org/wiki/Hierarchical_Data_Format：

HDF supports several different data models, including multidimensional arrays, raster images, and tables.

它也像文件系统一样具有层次结构，但是数据存储在一个魔术二进制文件中。

HDF5 is a suite that makes possible the management of extremely large and complex data collections.

想想PB级的NASA / JPL遥感数据。

回答

全文数据库，可以使用接近运算符查询，例如" 10个字以内"等。

关系数据库是一种理想的业务工具，其目的很容易理解和设计，足够快，足够，即使不是由天才可以"充分利用"的天才设计和优化的。

但是某些业务目的需要全文索引，而关系引擎或者不提供，或者事后才考虑。特别是，法律和医学领域有大量的非结构化文本可以存储和使用。

回答

几年前有一个名为JADE的RAD工具，它具有内置的OODBMS。 DB引擎的早期版本也支持Digitalk Smalltalk。如果要使用非RDBMS范例对应用程序构建进行示例，则可能是一个开始。

其他OODBMS产品包括Objectivity，GemStone(我们将需要获得VisualWorks Smalltalk才能运行Smalltalk版本，但也有一个Java版本)。在这个空间EXODUS及其后代SHORE中也有一些开源研究项目。

可悲的是，该概念似乎死了，可能是由于缺乏清晰可见的标准以及相对于基于SQL的RDMBS系统而言相对较差的即席查询功能。

OODBMS最适合具有核心数据结构的应用程序，这些数据最好以互连节点的图表示。我曾经说过，典型的OODBMS应用程序是一个多用户地牢(MUD)，其中的房间将包含玩家的化身和其他对象。

回答

还：
*嵌入式方案通常需要使用比完整RDBMS小一些的东西。 Db4o是在这种情况下可以轻松使用的ODB。
*快速或者概念验证的开发，我们希望专注于业务而不用担心持久层

回答

如果不需要ACID，则可能不需要RDBMS的开销。因此，请确定我们是否首先需要它。此处提供的大多数非RDBMS答案都不提供ACID。

回答

K.I.S.S：保持小巧简单

回答

我强烈建议使用Lua替代SQLite类的数据存储。

因为：

• 该语言最初被设计为数据描述语言。
• 语法是人类可读的(不是XML)
• 可以将Lua块编译为二进制文件，以提高性能

这是已接受答案的"本机语言收集"选项。如果我们使用C / C ++作为应用程序级别，则仅出于读取配置/数据或者将其写入的目的而引入Lua引擎(100kB二进制)是完全合理的。

回答

CAP定理简洁地解释了它。 SQL主要提供"强大的一致性：即使存在更新，所有客户端也会看到相同的视图"。