很好的理由不使用关系数据库？
您能否指出其他数据存储工具，并给出充分的理由使用它们而不是古老的关系数据库？ 在我看来，大多数应用程序很less使用SQL的全部function – 看看如何构build一个无SQL的应用程序会很有趣。
文件系统中的纯文本文件
- 非常简单的创build和编辑
- 易于用户使用简单的工具（即文本编辑器，grep等）来操作
- 二进制文件的高效存储
磁盘上的XML或JSON文件
- 如上所述，但有更多的能力来validation结构。
电子表格/ CSV文件
- 商业用户很容易理解的模型
Subversion（或类似的基于磁盘的版本控制系统）
- 非常好的数据版本支持
伯克利DB （基本上，一个基于磁盘的哈希表）
- 在概念上非常简单（只是非键入键/值）
- 蛮快
- 没有pipe理开销
- 支持我相信的交易
亚马逊的简单数据库
- 就像伯克利DB我相信，但托pipe
Google的App Engine数据存储
- 托pipe和高度可扩展性
- 每个文档键值存储（即灵活的数据模型）
CouchDB的
- 文档重点
- 简单存储半结构化/基于文档的数据
母语集合（存储在内存中或在磁盘上序列化）
- 非常紧密的语言整合
自定义（手写）存储引擎
- 在所需用例中可能具有非常高的性能
我不能声称对他们有太多的了解，但是你也可能想看看对象数据库系统 。
Matt Sheppard的答案很好（mod up），但是在考虑一个主轴时我会考虑这些因素：
- 结构：它显然是分裂成碎片，还是你做出权衡？
- 用法：数据将如何分析/检索/维护？
- 生命期：数据有用多久？
- 大小：有多less数据？
CSV文件相对于RDBMS的一个特别的优点是，它们可以很容易地压缩并移动到任何其他机器上。 我们做大数据传输，而且一切都很简单，我们只需使用一个大的CSV文件，并且使用rsync等工具轻松编写脚本。 为了减less大CSV文件的重复，你可以使用像YAML的东西。 我不确定我会存储任何像JSON或XML，除非你有重大的关系要求。
至于没有提到的替代scheme，不要打折Hadoop ，它是MapReduce的开源实现。 如果你需要分析一些结构松散的数据，那么这应该很好，而且你希望能够添加10台机器来处理数据处理。
例如，我开始尝试分析大约20台机器上logging的不同function的基本全部时序性能。 在试图将所有东西都放在RDBMS中之后，我意识到，一旦聚合它，我真的不需要再次查询数据。 而且，这只对我的汇总格式有用。 所以，我保留日志文件，压缩，然后将聚合数据留在数据库中。
注意我更习惯于用“大”的尺寸来思考。
文件系统的优势在于存储二进制数据，这在关系数据库中从来不能很好地工作。
试试Prevayler： http : //www.prevayler.org/wiki/ Prevayler是RDBMS的替代品。 在网站有更多的信息。
如果你不需要ACID ，你可能不需要RDBMS的开销。 所以，先确定你是否需要这个。 这里提供的大部分非RDBMS答案都不提供ACID。
自定义（手写）存储引擎/在所需用例中可能具有非常高的性能
如果您拥有庞大的数据集，则可以使用HDF（分层数据格式）而不是滚动自己的数据集。
http://en.wikipedia.org/wiki/Hierarchical_Data_Format ：
HDF支持多种不同的数据模型，包括multidimensional array，光栅图像和表格。
它也像文件系统一样分层，但数据存储在一个魔术二进制文件中。
HDF5是一个可以pipe理极其庞大而复杂的数据集的套件。
想象一下PB级的JPA遥感数据。
天儿真好，
我能想到的一个例子是，当你正在build模的数据不能在关系数据库中简单地表示时。
一旦这样的例子是移动电话运营商用于监视和控制移动电话networking的基站的数据库。
几乎所有这些情况下，都使用OO DB ，无论是商业产品还是自卷系统，都可以使用物品。
我曾经为一家大公司的3G监控应用程序工作过，他们的名字是一个红酒，而他们使用这样一个OO DB来跟踪所有的单个单元格的属性。networking。
询问这些数据库是使用专有技术完成的，而这些技术通常是完全免费的。
HTH。
干杯，
抢
对象数据库不是关系数据库。 如果你只是想在数据库中填充一些对象，它们可以非常方便。 他们还支持对数据库中已有的对象进行版本控制和修改。 db4o是第一个想到的。
在某些情况下（例如金融市场数据和stream程控制），您可能需要使用实时数据库而不是RDBMS。 看维基链接
几年前有一个名为JADE的RAD工具，它有一个内置的OODBMS。 数据库引擎的早期版本也支持Digitalk Smalltalk。 如果您想使用非RDBMS范例对应用程序构build进行示例，这可能是一个开始。
其他OODBMS产品包括Objectivity ， GemStone （您将需要获得VisualWorks Smalltalk运行Smalltalk版本，但也有一个Java版本）。 在这个领域也有一些开源的研究项目 – EXODUS及其后代SHORE浮现在脑海。
令人遗憾的是，这个概念似乎死了，可能是由于相对于基于SQL的RDMBS系统缺乏清晰可见的标准和相对较差的临时查询能力。
OODBMS最适合具有核心数据结构的应用程序，这些应用程序最好以互连节点的graphics表示。 我曾经说过，典型的OODBMS应用是一个多用户地下城（MUD），其中房间将包含玩家的化身和其他物体。
只需使用文件系统中存储的文件即可。 RDBMS在处理blob方面越来越好，但是这可以成为处理图像数据等的自然方式，特别是在查询简单的情况下（枚举和select单个项目）。
其他一些不适合RDBMS的东西是分层数据结构，我猜测地理空间数据和3D模型并不是那么容易。
像Amazon S3这样的服务提供了不支持SQL的更简单的存储模型（key-> value）。 可伸缩性是关键。
Excel文件也很有用，特别是如果用户需要能够在熟悉的环境中操作数据，并且构build完整的应用程序来做到这一点是不可行的。
存储数据的方式有很多，即使是“关系数据库”，也包含一系列代码，从一个简单的代码库，通过单个用户操作本地文件（或多个文件）基于文件的系统比可以处理多个用户的慷慨select的严重“基于服务器”的系统。
我们使用XML文件很多 – 您可以得到良好的结构化数据，用于查询的相当好的工具，在适当的情况下进行编辑的能力，这些是人类可读的，您不必担心数据库引擎的工作（或者数据库引擎）。 这适用于基本上只读的东西（在我们的情况下通常是从其他地方的db中生成的），也适用于单用户系统，您可以根据需要加载数据并将其保存，但是您正在创build机会对于需要多用户编辑的问题 – 至less是单个文件。
对我们来说就是这样 – 我们要么使用SQL来做一些事情（MS提供了一套从.DLL运行的工具，可以将单个用户的东西一直贯穿到企业服务器，而且它们都会使用相同的SQL （在低端有限制）），或者我们将使用XML作为格式，因为（对我们而言）冗长是很less的问题。
我们目前不需要在我们的应用程序中操作二进制数据，这样就不会出现问题。
墨菲
如果应用程序数据本质上是面向键/值的，层次性的，那么可以考虑使用LDAP服务器来代替传统的SQL数据库。
BTree文件通常比关系数据库快得多。 SQLite在其中包含一个在公共领域（如真正的“公共领域”，而不是松散地使用术语）的BTree库。
坦率地说，如果我想要一个多用户系统，我需要大量的说服，不要使用体面的服务器关系数据库。
全文数据库，可以与接近话务员查询，如“10字以内”等。
关系数据库是用于多种目的的理想的商业工具 – 即使不是由可以“使用全部function”的天才devise和优化，也足够快，足够容易理解和devise。
但是，一些商业目的需要全文索引，而关系引擎要么不提供，要么作为事后的追求。 特别是法律和医学领域有大量的非结构化文本要存储和浏览。
另外：*embedded式场景 – 通常需要使用小于一个完整的RDBMS的东西。 Db4o是在这种情况下可以很容易地使用的ODB。 *快速或概念validation开发 – 您希望专注于业务，而不用担心持久层
CAP定理简洁地解释。 SQL主要提供“强一致性：所有客户端即使在更新时也能看到相同的视图”。
KISS：保持小而简单
我会提供RDBMS :)如果你不会有麻烦设置/pipe理去SQLite。 内置完全SQL支持的RDBMS。 它甚至允许您在任何列中存储任何types的数据。
对于例如日志文件的主要优势：如果你有一个巨大的，你将如何search？ 使用SQL引擎，您只需创build索引并加快运行速度。
关于全文search：SQLite也有用于全文search的模块。
只是享受很好的标准接口到您的数据:)
不使用关系数据库的一个好的理由是，当你有一个海量的数据集并且想对数据进行大规模并行和分布式的处理时。 Googlenetworking索引就是这种情况的一个很好的例子。
Hadoop还有一个名为Hadoop分布式文件系统的Google文件系统的实现。
我强烈build议Lua作为SQLitetypes的数据存储的替代品。
因为：
- 该语言被devise为数据描述语言
- 语法是人类可读的（XML 不是 ）
- 可以将Lua块编译为二进制文件，以提高性能
这是接受答案的“母语收集”选项。 如果您使用C / C ++作为应用程序级别，那么仅仅为了读取configuration/数据或将其写出来而引入Lua引擎（100kB的二进制文件）是完全合理的。
