在开发软件大约5年后，我花了大约20％，也许高达40％的时间只是让RDBMS能够保存和检索复杂的对象图。很多时候，这导致了不太理想的编码解决方案，以便从数据库端更容易做到。在学习NHibernate和作为其一部分的会话管理模式花费了大量时间之后，这最终结束了。使用NHibernate，我终于避免了大部分100％浪费时间写入CRUD的第1000次，并使用我的域模型向前生成我的数据库。
然而，所有这些工作仍然导致一个有缺陷的模型，我的数据库只是SQL模仿我的实际对象的最佳尝试。对于文档数据库，不再是这种情况，因为对象变为文档本身，而不是仅通过表和列模拟对象。
此时我真的开始质疑为什么我会再次需要SQL？
使用SQL比用文档数据库更好地实质上做什么？
我知道这在一定程度上导致了从苹果到橙子的比较，特别是当你考虑到各种类型的具有广泛不同的特征集的NoSQL数据库时，但为了这个论点，它基于NoSQL数据库的概念本来就可以正确查询对象而不是键值存储的限制。还要忽略报告方面，因为通常应在OLAP数据库中处理，除非您的答案包含您不会使用OLAP数据库的特定原因。
答案 0 :(得分：30)
在亚马逊，我使用了很多代码。我工作过的大部分代码都是代码，没有人真正理解了。它充满了特殊的案件处理，但是很难理解，因为它在很长一段时间内都是快速补丁。如果你想完全理解你所做的改变的影响，那你就是运气不好。实质上，你被迫增加了吸积。
我还处理了大量数据。 SQL中表的结构为数据提供了出色的长期文档。数据库相对容易直接使用，数据结构很有意义。有些人的工作是管理数据的结构和完整性。
我担心NoSQL数据库缺乏记录良好的结构，会慢慢获得我所使用的代码的所有邪恶特性。它最终将填满旧结构的数据，而这些数据已经没有人真正理解了，并且变成了大多数无用的垃圾。
我认为SQL数据库的主要好处是维护数据库结构和一致性规则所需的强制文档。这些好处没有简单的短期措施，如查询速度或事务一致性。它们是长期的好处，会在很长一段时间内影响数据的有用性。
作为第二个相关点，我发现在使用ORM等时，映射出我的数据然后决定如何将其转换为我正在编写的应用程序中的对象更有用。数据及其关系代表了可用于各种目的的长期档案结构。
应用程序中对象关系的结构是出于该应用程序的目的。 SQL表和关系约束中表示的给定数据集将具有许多可能在应用程序中表示它的对象模型，并且每个对象模型将反映该特定应用程序的目标。但是数据及其结构独立于任何可能由它们组成的短暂使用而存在。
我认为人们对“报告”的论点是不同的应用程序可以以非常不同的方式有用地查看同一组数据的论据。
就个人而言，我认为SQL是一个很好的模型，可以直接用于存档数据，不经常修改的数据或具有极高一致性要求的数据。而且我认为我将继续使用关系代数来定义我的数据的整体结构，即使我将它存储在NoSQL数据库中。如果不先修改描述它的关系结构，我就不会改变NoSQL数据库中数据的结构。这将允许我将我的NoSQL数据库映射回SQL，因此我仍然可以使用SQL进行长期存储和仓储，并迫使我以一个记录良好的形式维护数据结构。
当我必须从NoSQL数据库中提取数据以便在创建数据库时未设想的应用程序中使用时，以这种方式执行操作也会对我有所帮助。
当然，有些数据的结构自然适合NoSQL，而为它生成关系模式则毫无意义。例如，存储实际文档，存储图片或其他媒体，或其他没有可能有用的结构的大数据。但这种区别非常棘手。图片和电影确实具有结构，只是通常不需要存储在数据库中的结构。如果你有一个旨在尝试阅读和理解它的系统，博客文章也可能有结构，这可能是你想要保留记录的结构。
答案 1 :(得分：29)
关系数据建模是一种形式化的数学解决方案，用于表示没有冗余且不允许异常的复杂数据。您可以从数据关系本身设计最佳数据库设计。这是关系database normalization的过程。
非关系数据建模没有正式的方法来从数据中定义最佳数据库结构。您可以根据预期的使用情况设计数据库;也就是说，您的查询确定最佳数据组织，而不是数据本身。
在非关系数据库中，您永远无法确定数据是否符合某种文档结构。您可以从早期版本的数据库中保留文档。因此，您的应用程序代码最好能够“发现”每个文档的结构，在必要时执行转换，并希望数据集合之间的引用得到满足。
在关系数据库中，您可以依赖数据完整性作为模型的组成部分。如果你设计标准化并正确设置约束，你就知道你永远不会有孤儿或数据异常。
在设计数据库时，非关系数据库为您提供了一种效率。关系数据库为您提供了另一种效率，因为您使用数据库。
也就是说，您使用的特定类型的问题 - 对象图 - 使用纯SQL有效地完成。但我认为你会发现使用NoSQL数据库并不容易。
重新评论：当然，consistency不是每个应用的优先级。对于重要的应用程序而言，这并不会使一致性的价值“非实质性”。
您询问了为什么要使用关系数据库 - 当关系数据库的好处符合项目的优先级时，您就会使用它们。
不要用螺丝刀钉钉子，也不要用锤子拧螺丝。有一个合适的工具可以解决每种类型的问题。
答案 2 :(得分：5)
这取决于你想要做什么。当你需要在对象的不同字段上进行搜索时，SQL就是好的。如果您不需要进行搜索，并且您具有非常复杂的多态树状结构，则SQL非常糟糕。
我曾在app上工作，允许用户通过将小片段连接在一起来构建网页，而原始序列化使用了键/值SQL表。所有片段都具有存储的属性（片段，属性，值）。如此无模式，但仍然很繁重。可能是两个世界中最糟糕的，因为你没有从数据库中获得太多的数据验证，很难查看表并理解发生了什么，并且仍然有很多工作要将它写入数据库并且读回来。
我们也做了类似的应用程序但是我们吸取了教训，我们只使用普通的java类并使用JSON对它们进行编码。用户只需在富有的ui中编辑前面的页面。单击“保存”，整个页面将作为json对象发送回服务器。然后服务器对对象进行验证，以确保所有约束都是正确的，除非用户已被篡改或代码中存在错误，否则应始终为真。然后通过编码将对象写入一行以返回json。
这对我们很有用，因为我们从不想处理部分对象。我们总是处理整个对象，所以JSON不仅更容易，而且比每次读取的40多个查询更快，如果它被正确规范化，我们必须做。
答案 3 :(得分：0)
SQL的工具要好得多。 NoSql声名狼借。但即使假设这两个差异甚至出来......
我在SQL中编写复杂对象时遇到了相反的经验。要说表和列充其量只是对象的“仿真”，这有点语义。您的对象的任何序列化也将是一种模拟：虽然文档数据库或xml或其他任何可能感觉比表/列更好的模拟，但它往往是功能较弱的技术。 ORM帮助极大地缩小了从RBDMS到面向对象语言的差距。
自从关系理论形式化以来，SQL一直是王道。分层dbs（文档数据库）丢失，关系dbs赢了。我会问你自己，鉴于历史，你的问题与过去30年中你需要恢复到等级形式的大多数问题有什么不同？
对于需要水平扩展的问题（现在SQL不能很好），NoSql dbs现在很流行。你的问题需要吗？
答案 4 :(得分：0)
不仅有SQL数据库的变体，每个都有自己的优点和缺点。
有基于文档或对象，基于列（宽行），基于键值和基于图形，这只是我现在能想到的。每种类型的数据库都有其弱点和强项（与其他数据库和RDBMS相比）。
在决定选择哪种数据库类型时，您需要问自己的真正问题是如何使用数据？
在大多数常见情况下，至少直到某种程度的对象复杂性，对于非大数据，RDBMS更少关注数据的使用方式以及数据本身的更多信息。在RDBMS中，您只需要知道您的数据结构和内部关系，在您意识到这一点之后，您只需将其置于正常的表单模式中，如果您使用正确的密钥和索引，您就可以在大多数查询中获得性能。
在NoSQL数据库中，它更为重要，例如基于文档的数据库的一个特定弱点是，如果在大多数情况下需要对多个文档进行复杂查询，那么您将无法获得比RDBMS更好的性能。 / p>
例如，如果您要维护订单文档，并希望查询订单中包含在一系列日期中获得的最大利润，那么如果您不是专家（因为我不是这样），您将最终有一个O（n）查询，而在RDBMS中，即使你是MongoDB专家，它也会花费更少，而且肯定会更高效。
总之，如果您事先知道您的数据将如何使用，并且您知道文档数据库对您的用例有效，那么，请带上该文档数据库，但如果您不确定您的数据如何将被使用，比RDBMS通常会更明智的决定。
当然，你需要考虑BigData的理论，因为RDBMS不会扩展（不能轻易添加节点以支持更多流量），并且在处理巨大数据时性能会降低（可能会开始滞后）在GB或PB中）。
另外，请记住，RDBMS比历史数据库更老，并且已经广泛开发，这使得RDBMS包含比任何NoSQL替代品更多的优化和工具。
答案 5 :(得分：0)
NO-SQl表示-非关系数据库！
NoSQL数据库对于可伸缩性很重要的大型应用程序更好。
Nosql数据库的插入和获取都很快速
NoSQL数据库的获取记录比sql数据库快10倍
可伸缩且灵活的数据存储区：这是远离关系数据库的主要原因。
它可以处理结构化和非结构化数据。它使用集合而不是表格
答案 6 :(得分：-1)
当我调查noSQL风格的数据库时，我发现他们没有提供ACID，也没有提供关系功能（不是关系数据库）。由于我喜欢数据一致性，而且我通常想要某种关系特性，所以我没有选择noSQL数据库。
但是，我没有使用ORM工具，我倾向于编写SQL本身。
答案 7 :(得分：-1)
重要的是要记住，关系仍然（并将继续存在一段时间）选择的平台：事务处理，主数据管理，参考数据，数据仓库（在MPP中），BI（尽管倒置列）数据库在查询性能方面表现突出）。鉴于目前的NOSQL状态，它可以取代上述用途的关系，这几乎是荒谬的。
答案 8 :(得分：-2)
我的关键问题是SQL数据库在哪里真正优于文档数据库，并且从所有响应中确实看起来并不多。
鉴于NoSQL数据库的数据库类型与关系数据库的数量不同，它们都匹配ACID的全部或部分部分，具体取决于您使用的数据库，此时它们基本上是解决问题的公平。
在此之后，关键的差异将是工具和成熟度，SQL数据库对于成为已建立的玩家有更大的把握，但这就是所有新技术的方式。
答案 9 :(得分：-2)
我看待这个问题的方式恰恰相反：为什么我根本不需要没有SQL？
SQL为我提供了关系建模，事务，触发器，键，约束，动态模式，可以在眨眼间修改YET保证数据完整性，快速复杂的查询数据，以最纯粹和最清晰的形式表示
你的问题是你试图将方形钉固定在圆孔中：对象和rdbms不能很好地结合在一起，因为RDBMS旨在处理许多更复杂的get / set逻辑，并强制执行一致性，这正是您对对象图层的期望。
Protip：删除对象，它们不适合这项工作。