SQL 不使用关系数据库的好理由？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/37823/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Good reasons NOT to use a relational database?
提问by caustic
Can you please point to alternative data storage tools and give good reasons to use them instead of good-old relational databases? In my opinion, most applications rarely use the full power of SQL--it would be interesting to see how to build an SQL-free application.
您能否指出替代数据存储工具并给出使用它们而不是旧关系数据库的充分理由？在我看来，大多数应用程序很少使用 SQL 的全部功能——看看如何构建一个无 SQL 的应用程序会很有趣。
回答by Matt Sheppard
Plain text files in a filesystem
文件系统中的纯文本文件
- Very simple to create and edit
- Easy for users to manipulate with simple tools (i.e. text editors, grep etc)
- Efficient storage of binary documents
- 创建和编辑非常简单
- 用户可以使用简单的工具（即文本编辑器、grep 等）轻松操作
- 二进制文件的高效存储
XML or JSON files on disk
磁盘上的 XML 或 JSON 文件
- As above, but with a bit more ability to validate the structure.
- 如上所述，但具有更多验证结构的能力。
Spreadsheet / CSV file
电子表格/CSV 文件
- Very easy model for business users to understand
- 商业用户非常容易理解的模型
Subversion (or similar disk based version control system)
Subversion（或类似的基于磁盘的版本控制系统）
- Very good support for versioning of data
- 非常好的数据版本支持
Berkeley DB(Basically, a disk based hashtable)
Berkeley DB（基本上是一个基于磁盘的哈希表）
- Very simple conceptually (just un-typed key/value)
- Quite fast
- No administration overhead
- Supports transactions I believe
- 概念上非常简单（只是未键入的键/值）
- 蛮快
- 无管理开销
- 支持交易我相信
- Much like Berkeley DB I believe, but hosted
- 我相信很像伯克利数据库，但托管
- Hosted and highly scalable
- Per document key-value storage (i.e. flexible data model)
- 托管且高度可扩展
- 每个文档的键值存储（即灵活的数据模型）
- Document focus
- Simple storage of semi-structured / document based data
- 文档焦点
- 简单存储半结构化/基于文档的数据
Native language collections (stored in memory or serialised on disk)
本机语言集合（存储在内存中或在磁盘上序列化）
- Very tight language integration
- 非常紧密的语言集成
Custom (hand-written) storage engine
自定义（手写）存储引擎
- Potentially very high performance in required uses cases
- 在所需的用例中可能具有非常高的性能
I can't claim to know anything much about them, but you might also like to look into object database systems.
我不能声称对它们有太多了解，但您可能还想研究对象数据库系统。
回答by Tristan Juricek
Matt Sheppard's answer is great (mod up), but I would take account these factors when thinking about a spindle:
马特谢泼德的回答很好（修改），但在考虑纺锤时我会考虑这些因素：
- Structure : does it obviously break into pieces, or are you making tradeoffs?
- Usage : how will the data be analyzed/retrieved/grokked?
- Lifetime : how long is the data useful?
- Size : how much data is there?
- 结构：它是否明显分解成碎片，或者您是否在进行权衡？
- 用法：如何分析/检索/了解数据？
- Lifetime ：数据有用多久？
- 大小：有多少数据？
One particular advantage of CSV files over RDBMSes is that they can be easy to condense and move around to practically any other machine. We do large data transfers, and everything's simple enough we just use one big CSV file, and easy to script using tools like rsync. To reduce repetition on big CSV files, you could use something like YAML. I'm not sure I'd store anything like JSON or XML, unless you had significant relationship requirements.
CSV 文件相对于 RDBMS 的一个特殊优势是它们可以很容易地压缩并移动到几乎任何其他机器上。我们进行大数据传输，一切都很简单，我们只使用一个大的 CSV 文件，并使用 rsync 等工具轻松编写脚本。为了减少大型 CSV 文件的重复，您可以使用类似YAML 的内容。我不确定是否会存储 JSON 或 XML 之类的内容，除非您有重要的关系要求。
As far as not-mentioned alternatives, don't discount Hadoop, which is an open source implementation of MapReduce. This should work well if you have a TON of loosely structured data that needs to be analyzed, and you want to be in a scenario where you can just add 10 more machines to handle data processing.
至于没有提到的替代方案，不要小看 Hadoop，它是 MapReduce 的一个开源实现。如果您有大量结构松散的数据需要分析，并且您希望处于这样的场景中，您只需添加 10 台机器来处理数据处理，这应该很有效。
For example, I started trying to analyze performance that was essentially all timing numbers of different functions logged across around 20 machines. After trying to stick everything in a RDBMS, I realized that I really don't need to query the data again once I've aggregated it. And, it's only useful in it's aggregated format to me. So, I keep the log files around, compressed, and then leave the aggregated data in a DB.
例如，我开始尝试分析性能，这些性能基本上是在大约 20 台机器上记录的不同功能的所有计时数字。在尝试将所有内容都放入 RDBMS 后，我意识到一旦聚合数据，我真的不需要再次查询数据。而且，它仅在聚合格式对我有用。因此，我保留日志文件并进行压缩，然后将聚合数据留在数据库中。
NoteI'm more used to thinking with "big" sizes.
请注意，我更习惯于考虑“大”尺寸。
回答by Ubiguchi
The filesystem's prety handy for storing binary data, which never works amazingly well in relational databases.
文件系统对于存储二进制数据非常方便，但它在关系数据库中从来没有表现出惊人的效果。
回答by zaca
Try Prevayler: http://www.prevayler.org/wiki/Prevayler is alternative to RDBMS. In the site have more info.
试试 Prevayler：http: //www.prevayler.org/wiki/Prevayler 是 RDBMS 的替代品。在网站上有更多信息。
回答by Jared Updike
Custom (hand-written) storage engine / Potentially very high performance in required uses cases
自定义（手写）存储引擎/在所需用例中可能具有非常高的性能
If you have enormous data sets, instead of rolling your own, you might use HDF, the Hierarchical Data Format.
如果您有庞大的数据集，您可以使用 HDF（分层数据格式）而不是滚动自己的数据集。
http://en.wikipedia.org/wiki/Hierarchical_Data_Format:
http://en.wikipedia.org/wiki/Hierarchical_Data_Format：
HDF supports several different data models, including multidimensional arrays, raster images, and tables.
HDF 支持多种不同的数据模型，包括多维数组、光栅图像和表格。
It's also hierarchical like a file system, but the data is stored in one magic binary file.
它也像文件系统一样分层，但数据存储在一个神奇的二进制文件中。
HDF5 is a suite that makes possible the management of extremely large and complex data collections.
HDF5 是一个套件，可以管理极其庞大和复杂的数据集合。
Think petabytes of NASA/JPL remote sensing data.
想想 PB 级的 NASA/JPL 遥感数据。
回答by bzlm
回答by Rob Wells
G'day,
G'day,
One case that I can think of is when the data you are modelling cannot be easily represented in a relational database.
我能想到的一种情况是，您正在建模的数据无法在关系数据库中轻松表示。
Once such example is the database used by mobile phone operators to monitor and control base stations for mobile telephone networks.
一个这样的例子是移动电话运营商使用的数据库来监视和控制移动电话网络的基站。
I almost all of these cases, an OO DBis used, either a commercial product or a self-rolled system that allows heirarchies of objects.
我几乎在所有这些情况下都使用了OO DB，无论是商业产品还是允许对象层次结构的自卷系统。
I've worked on a 3G monitoring application for a large company who will remain nameless, but whose logo is a red wine stain (-: , and they used such an OO DB to keep track of all the various attributes for individual cells within the network.
我曾为一家大公司开发 3G 监控应用程序，该公司将保持匿名，但其徽标是红酒渍（-: ，他们使用这样的 OO DB 来跟踪单个单元格内的所有各种属性网络。
Interrogation of such DBs is done using proprietary techniques that are, usually, completely free from SQL.
此类数据库的查询是使用专有技术完成的，这些技术通常完全不受 SQL 影响。
HTH.
哈。
cheers,
干杯，
Rob
抢
回答by Chris de Vries
Object databases are not relational databases. They can be really handy if you just want to stuff some objects in a database. They also support versioning and modify classes for objects that already exist in the database. db4ois the first one that comes to mind.
对象数据库不是关系数据库。如果您只想在数据库中填充一些对象，它们会非常方便。它们还支持版本控制和修改数据库中已存在对象的类。db4o是第一个想到的。
回答by horace
回答by ConcernedOfTunbridgeWells
There was a RAD tool called JADE written a few years ago that has a built-in OODBMS. Earlier incarnations of the DB engine also supported Digitalk Smalltalk. If you want to sample application building using a non-RDBMS paradigm this might be a start.
几年前有一个名为JADE的 RAD 工具，它有一个内置的 OODBMS。DB 引擎的早期版本也支持 Digitalk Smalltalk。如果您想使用非 RDBMS 范例对应用程序构建进行示例，这可能是一个开始。
Other OODBMS products include Objectivity, GemStone(You will need to get VisualWorksSmalltalk to run the Smalltalk version but there is also a java version). There were also some open-source research projects in this space - EXODUS and its descendent SHORE come to mind.
其他 OODBMS 产品包括Objectivity、GemStone（您需要获得VisualWorksSmalltalk 才能运行 Smalltalk 版本，但也有一个 Java 版本）。在这个领域也有一些开源研究项目——EXODUS 和它的后代 SHORE 浮现在脑海中。
Sadly, the concept seemed to die a death, probably due to the lack of a clearly visible standard and relatively poor ad-hoc query capability relative to SQL-based RDMBS systems.
可悲的是，这个概念似乎已经消亡，可能是由于缺乏清晰可见的标准以及相对于基于 SQL 的 RDMBS 系统的相对较差的即席查询能力。
An OODBMS is most suitable for applications with core data structures that are best represented as a graph of interconnected nodes. I used to say that the quintessential OODBMS application was a Multi-User Dungeon (MUD) where rooms would contain players' avatars and other objects.
OODBMS 最适合具有核心数据结构的应用程序，这些数据结构最好表示为互连节点图。我曾经说过，典型的 OODBMS 应用程序是一个多用户地牢 (MUD)，其中房间将包含玩家的头像和其他对象。
