关于sql：有充分理由不使用关系数据库吗？

Good reasons NOT to use a relational database?

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

在文件系统中放置纯文本文件

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

磁盘上的XML或JSON文件

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

电子表格/ CSV文件

商业用户易于理解的模型

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

很好地支持数据版本控制

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

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

亚马逊的简单数据库

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

Google的App Engine数据存储区

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

CouchDB

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

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

非常紧密的语言集成

自定义(手写)存储引擎

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

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

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

结构：它显然会分解成碎片，还是在进行权衡？

用法：将如何分析/检索/收集数据？

生命周期：数据有用多长时间？

大小：有多少数据？

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

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

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

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

用于存储二进制数据的文件系统非常方便，在关系数据库中它永远无法正常运行。

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

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

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遥感数据。

G'day，

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

一旦这样的示例，移动电话运营商就会使用该数据库来监视和控制移动电话网络的基站。

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

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

通常使用完全不依赖SQL的专有技术来查询此类DB。

HTH。

干杯，

Rob

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

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

其他OODBMS产品包括Objectivity，GemStone(您将需要获得VisualWorks Smalltalk才能运行Smalltalk版本，但也有一个Java版本)。在这个领域中还有一些开源研究项目-EXODUS及其后代SHORE浮现在脑海。

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

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

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

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

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

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

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

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

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

有许多种存储数据的方法-甚至"关系数据库"也涵盖了操作本地文件的简单代码库中的一系列替代方法，就好像它是单个用户上的关系数据库一样。因此，通过基于文件的系统，可以处理多个用户，以选择大量的基于"服务器"的严重系统。

我们大量使用XML文件-您会获得结构良好的数据，用于查询的良好工具(如果适用)进行编辑的能力，易于理解的内容，因此您不必担心db引擎的工作(或数据库引擎的工作原理)。这对于本质上是只读的东西(在我们的情况下，通常不是从其他地方的数据库生成的东西)以及单用户系统中都非常有用，在单用户系统中，您只需加载数据并根据需要将其保存出来即可，但是您正在创造机会如果您想进行多用户编辑-至少要编辑一个文件，则会出现问题。

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

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

水墨

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

我会提供RDBMS ：)
如果您不会在设置/管理方面遇到麻烦，请使用SQLite。
内置的RDBMS具有完整的SQL支持。它甚至允许您将任何类型的数据存储在任何列中。

例如，相对于日志文件的主要优点：如果有大量日志文件，该如何搜索？使用SQL引擎，您只需创建索引并显着加快操作速度。

关于全文搜索：SQLite也具有用于全文搜索的模块。.

只需享受数据的漂亮标准接口即可：)

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

关系数据库是用于多种目的的理想业务工具-易于理解和设计，足够快速，足够，即使不是由可以"使用全部功能"的天才设计和优化的。 >

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

也：
*嵌入式方案-通常要求使用比成熟的RDBMS小一些的方案。 Db4o是在这种情况下可以轻松使用的ODB。
*快速或概念验证的开发-您希望专注于业务而不用担心持久层