请您指出替代数据存储工具并提供充分的理由来使用它们而不是旧的关系数据库？在我看来，大多数应用程序很少使用SQL的全部功能 - 看看如何构建一个没有SQL的应用程序会很有趣。
答案 0 :(得分：148)
文件系统中的纯文本文件
磁盘上的XML或JSON文件
电子表格/ CSV文件
Subversion（或类似的基于磁盘的版本控制系统）
Berkeley DB（基本上是基于磁盘的哈希表）
母语集合（存储在内存中或在磁盘上序列化）
自定义（手写）存储引擎
我不能声称对此有任何了解，但您可能也想查看object database systems。
答案 1 :(得分：26)
Matt Sheppard的答案很棒（mod up），但在考虑主轴时我会考虑这些因素：
CSV文件相对于RDBMS的一个特殊优势是它们可以很容易地压缩并移动到几乎任何其他机器上。我们进行大量数据传输，一切都很简单，我们只使用一个大的CSV文件，并且使用rsync等工具轻松编写脚本。为减少大型CSV文件的重复，您可以使用YAML之类的内容。我不确定我会存储JSON或XML之类的东西，除非你有很重要的关系要求。
就未提及的替代方案而言，不要打折Hadoop，这是MapReduce的开源实现。如果您有大量需要分析的结构松散的数据，并且您希望处于可以添加10台机器来处理数据处理的情况下，这应该可以正常工作。
例如，我开始尝试分析基本上所有在20台机器上记录的不同功能的时序数的性能。在尝试将所有内容都放在RDBMS中之后，我意识到在汇总数据后我真的不需要再次查询数据。而且，它只对我的聚合格式有用。因此，我保留日志文件，压缩，然后将聚合数据保留在数据库中。
注意我更习惯于考虑“大”尺寸。
答案 2 :(得分：10)
文件系统非常方便用于存储二进制数据，这在关系数据库中从不能很好地工作。
答案 3 :(得分：6)
尝试Prevayler： http://www.prevayler.org/wiki/ Prevayler是RDBMS的替代品。在网站上有更多信息。
答案 4 :(得分：6)
如果您不需要ACID，则可能不需要RDBMS的开销。所以，先确定你是否需要它。这里提供的大多数非RDBMS答案不提供ACID。
答案 5 :(得分：6)
自定义（手写）存储引擎/在所需用例中可能具有非常高的性能
如果您拥有庞大的数据集，而不是自己滚动数据集，则可以使用HDF，即分层数据格式。
http://en.wikipedia.org/wiki/Hierarchical_Data_Format：
HDF支持多种不同的数据模型，包括多维数组，光栅图像和表格。
它也像文件系统一样分层，但数据存储在一个魔术二进制文件中。
HDF5是一个套件，可以管理极其庞大和复杂的数据集。
想想数PB的NASA / JPL遥感数据。
答案 6 :(得分：4)
天儿真好，
我能想到的一个案例是，您建模的数据无法在关系数据库中轻松表示。
这样的例子就是移动电话运营商用来监控移动电话网络基站的数据库。
我几乎所有这些情况都使用了OO DB，无论是商业产品还是自动滚动系统，都可以使用物品的层次结构。
我为一家大公司开发了一个3G监控应用程序，该公司将保持无名，但其徽标是红酒渍（ - ：，并且他们使用这样的OO DB来跟踪个人的所有各种属性网络中的细胞。
使用通常完全不受SQL的专有技术来查询此类数据库。
HTH。
欢呼声，
罗布
答案 7 :(得分：3)
对象数据库不是关系数据库。如果你只想在数据库中填充一些对象，它们可以非常方便。它们还支持版本控制和修改数据库中已存在的对象的类。 db4o是第一个浮现在脑海中的人。
答案 8 :(得分：3)
在某些情况下（例如金融市场数据和流程控制），您可能需要使用实时数据库而不是RDBMS。见wiki link
答案 9 :(得分：3)
几年前有一个名为JADE 的RAD工具，内置了OODBMS。数据库引擎的早期版本也支持Digitalk Smalltalk。如果您想使用非RDBMS范例对应用程序构建进行示例，这可能是一个开始。
其他OODBMS产品包括Objectivity，GemStone（您需要获取VisualWorks Smalltalk来运行Smalltalk版本，但也有一个java版本）。在这个领域也有一些开源研究项目 - EXODUS及其后代SHORE浮现在脑海中。
遗憾的是，这个概念似乎已经死亡，可能是由于缺乏明显可见的标准，而且与基于SQL的RDMBS系统相比，ad-hoc查询功能相对较差。OODBMS最适合具有最佳表示为互连节点图的核心数据结构的应用程序。我曾经说过，典型的OODBMS应用程序是一个多用户地牢（MUD），其中房间将包含玩家的头像和其他物体。
答案 10 :(得分：1)
我会提供RDBMS :) 如果你不习惯设置/管理麻烦去SQLite。 内置RDBMS，支持完整的SQL。它甚至允许您在任何列中存储任何类型的数据。
例如日志文件的主要优势：如果你有一个巨大的文件，你将如何搜索它？使用SQL引擎，您只需创建索引并加速操作。
关于全文搜索：SQLite也有全文搜索模块..
只需享受数据的漂亮标准界面：）
答案 11 :(得分：1)
CAP theorem简洁地解释了这一点。 SQL主要提供“强一致性：即使存在更新，所有客户端也会看到相同的视图”。
答案 12 :(得分：1)
K.I.S.S：保持小而简单
答案 13 :(得分：1)
此外： *嵌入式场景 - 通常需要使用比完整的RDBMS更小的东西。 Db4o是一种可以在这种情况下轻松使用的ODB。 *快速或概念验证开发 - 您希望专注于业务而不必担心持久层
答案 14 :(得分：1)
全文数据库，可以通过邻近运算符查询，例如“10个字以内”等。
关系数据库是一个理想的商业工具，用于多种用途 - 即使它们不是由能够“充分利用全部功能”的天才设计和优化的，也足够快速地理解和设计，足够快，足够。
但是一些商业目的需要全文索引，而关系引擎要么不提供也要作为事后补救。特别是，法律和医学领域有大量的非结构化文本来存储和浏览。
答案 15 :(得分：1)
BTree文件通常比关系数据库快得多。 SQLite在其中包含一个BTree库，该库位于公共领域（如真正的“公共领域”，不使用松散的术语）。
但是，坦率地说，如果我想要一个多用户系统，我需要大量的说服力，不要使用体面的服务器关系数据库。答案 16 :(得分：1)
如果应用程序数据具有严格的关键/价值取向和层次性，则可能需要考虑使用LDAP服务器代替传统的SQL数据库。
答案 17 :(得分：1)
存在大量存储数据的方法 - 甚至“关系数据库”也涵盖了一系列替代方案，这些方法来自操作本地文件（或文件）的简单代码库，就好像它是单个用户的关系数据库一样基础，通过基于文件的系统，可以处理多个用户到慷慨的选择严重的“服务器”系统。
我们经常使用XML文件 - 你得到结构良好的数据，用于查询的好工具，如果合适的话，可以进行编辑，人类可读的东西，你不必担心数据库引擎工作（或者数据库引擎的工作方式）。这适用于基本上只读的东西（在我们的情况下，通常是从其他地方的数据库生成），也适用于单个用户系统，您可以根据需要加载数据并将其保存 - 但是您正在创造机会如果你想要多用户编辑问题 - 至少是一个文件。
对于我们而言 - 我们要么会使用能够做SQL的东西（MS提供一套从.DLL运行的工具，一直到单个用户的东西一直到企业服务器，他们都会说话相同的SQL（在低端有限制））或者我们将使用XML作为格式，因为（对我们来说）冗长很少是一个问题。
我们目前不需要在我们的应用中操纵二进制数据，因此不会出现问题。
墨菲
答案 18 :(得分：1)
您只需使用存储在文件系统中的文件即可。 RDBMS在处理blob方面越来越好，但这可以是处理图像数据等的自然方式，特别是在查询很简单的情况下（枚举和选择单个项目。）
在RDBMS中不太适合的其他事情是分层数据结构，我猜测地理空间数据和3D模型也不容易使用。
Amazon S3之类的服务提供了不支持SQL的更简单的存储模型（key-＆gt; value）。可伸缩性是关键所在。
Excel文件也很有用，特别是如果用户需要能够在熟悉的环境中操作数据并构建完整的应用程序来做到这一点是不可行的。
答案 19 :(得分：0)
不使用关系数据库的一个好理由是，当您拥有海量数据集并希望对数据进行大规模并行和分布式处理时。谷歌网络索引将是这种情况的一个完美的例子。
Hadoop还有一个名为Google File System的Hadoop Distributed File System实现。
答案 20 :(得分：0)
我强烈建议使用Lua替代SQLite类数据存储。
由于：
这是已接受答案的“本地语言集合”选项。如果您使用C / C ++作为应用程序级别，那么只是为了读取配置/数据或将其写出来，抛出Lua引擎（100kB的二进制文件）是完全合理的。