不使用关系数据库的好理由？

文件系统在存储二进制数据方面非常方便，这在关系数据库中从来都不能很好地工作。

你好,

我能想到的一个例子是，你所建模的数据不能很容易地用关系数据库表示出来。

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

我几乎在所有这些案例中，都使用了 OO DB，它要么是一个商业产品，要么是一个允许对象层次结构的自滚动系统。

我曾经为一家大公司开发过一个3G 监控应用程序，这家公司的标志是一个红葡萄酒污渍(- : ，他们使用这样一个 OO DB 来跟踪网络中各个单元的所有不同属性。

对这种数据库的询问是使用专有技术完成的，这些技术通常完全不受 SQL 的限制。

高温。

干杯,

罗伯

文件系统中的纯文本文件

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

磁盘上的 XML 或 JSON 文件

• 和上面一样，但是具有更多验证结构的能力。

电子表格/CSV 文件

• 业务用户非常容易理解的模型

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

• 非常好的数据版本控制支持

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

• 概念上非常简单(只是没有类型化的键/值)
• 很快
• 没有管理费用
• 支持交易，我相信

亚马逊的简单数据库

• 很像伯克利数据库，我相信，但托管

Google 的 App Engine Datastore

• 托管和高度可伸缩性
• 每个文档键值存储(即灵活的数据模型)

CouchDB

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

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

• 非常紧密的语言集成

自定义(手写)存储引擎

• 在需要的用例中可能具有非常高的性能

我不能声称对他们有多少了解，但你可能也想了解一下 对象数据库系统对象数据库系统。

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

仅仅使用存储在文件系统中的文件就可以做很多事情。RDBMS 在处理 blob 方面做得越来越好，但这可能是处理图像数据之类的自然方法，特别是在查询很简单的情况下(枚举和选择单个项目)

其他不太适合 RDBMS 的东西是分层数据结构，我猜测地理空间数据和3D 模型也不是那么容易处理。

像 亚马逊 S3这样的服务提供了不支持 SQL 的更简单的存储模型(key-> value)。

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

试试普雷维勒: Http://www.prevayler.org/wiki/ Prevayler 是 RDBMS 的替代品。在网站上有更多的信息。

存储数据的方法有很多种——甚至“关系数据库”也包括一系列替代方法，从简单的代码库操作本地文件(或文件) ，就好像它是一个基于单个用户的关系数据库一样，通过基于文件的系统(可以处理多个用户) ，到大量选择严肃的基于“服务器”的系统。

我们经常使用 XML 文件——您可以获得结构良好的数据、用于查询相同功能的优秀工具，以及在适当时进行编辑的能力，还有一些人类可读的东西，这样您就不必担心数据库引擎的工作(或数据库引擎的工作)。这种方法适用于本质上只读的内容(在我们的例子中，通常不是从其他地方的数据库生成的) ，也适用于单用户系统，在这些系统中，您可以根据需要将数据加载进来并保存出来——但是如果您想要多用户编辑——至少是单个文件——那么您将为问题创造机会。

对于我们来说，这就是问题所在——我们要么使用一些可以执行 SQL 的工具(MS 提供了一组从。DLL 来做单用户的东西，一直到企业服务器，他们都说相同的 SQL (限制在低端) ，或者我们将使用 XML 作为一种格式，因为(对我们来说)冗长很少是一个问题。

我们目前不需要在我们的应用程序中操作二进制数据，这样就不会出现这个问题。

墨菲

Matt Sheppard 的答案很棒(现代化) ，但是当我考虑纺锤时，我会考虑这些因素:

1. 结构: 它是否明显地分解为多个部分，或者您正在进行权衡？
2. 用法: 如何分析/检索/获取数据？
3. 生命周期: 数据有用的时间有多长？
4. 大小: 有多少数据？

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

至于没有提到的替代方案，不要忽略 Hadoop，它是 MapReduce 的一个开源实现。如果您需要分析结构松散的数据，并且您希望处于这样一种场景中，即只需再添加10台机器来处理数据处理，那么这种方法应该能够很好地工作。

例如，我开始尝试分析性能，基本上就是在大约20台机器上记录的不同函数的计时数字。在尝试将所有内容都放入 RDBMS 之后，我意识到一旦聚合了数据，就真的不需要再次查询数据了。而且，它只有在它的聚合格式对我有用。因此，我将日志文件保存在周围，压缩，然后将聚合数据保留在数据库中。

注意: 我更习惯于用“大”尺寸来思考问题。