关系数据库与非关系数据库有什么区别？
我知道像MySQL，PostgreSQL和MS SQL Server这样的解决scheme是关系型数据库系统，而NoSQL，MongoDB等是非关系型DBMS。
但是，这两种系统有什么区别呢？
外行条件是可取的。
谢谢。
关系数据库有一个math基础（集合论， 关系理论 ），它们被提炼成SQL ==结构化查询语言。
NoSQL的许多forms（例如，基于文档的，基于graphics的，基于对象的，键值存储等）可能或可能不基于单一的基础math理论。 正如S. Lott所正确指出的那样， 分级数据存储确实有一个math基础。 graphics数据库也可以这样说。
我不知道NoSQL数据库的通用查询语言。
嗯，不太清楚你的问题是什么。
在关于数据库（DB）的标题中，而在文本的正文中则询问了数据库pipe理系统（DBMS）。 两者完全不同，需要不同的答案。
数据库pipe理系统是一个允许你访问数据库的工具。
除了数据本身之外，数据库就是数据结构的概念。
因此，就像您可以使用面向对象的方法，使用非OO驱动的编译器一样，或反之亦然，您可以在不使用RDBMS的情况下设置关系数据库，也可以使用RDBMS来存储非关系数据。
我将重点关注关系数据库（RDB）的含义，并将讨论关于系统对其他人的做法。
关系数据库（概念）是一种数据结构，它允许您链接来自不同“表”或不同types数据存储桶的信息。 数据桶必须包含所谓的密钥或索引（允许唯一标识桶中的任何primefaces数据块）。 其他数据桶可以引用该键，以便在其数据primefaces和该键所指向的primefaces之间build立链接。
非关系数据库只是存储数据，而没有显式和结构化的机制将不同桶中的数据链接到另一个桶中。
至于实现这样一个scheme，如果你有一个带有索引的纸质文件，并且在一个不同的纸质文件中，你可以参考索引来获得相关信息，那么你已经实现了一个关系数据库，尽pipe它很简单。 所以你可以看到你甚至不需要一台计算机（当然，如果没有人帮忙，它会很快变得乏味），同样你也不需要一个RDBMS，尽pipe可以说RDBMS是正确的工具。 这就是说，有什么不同的工具可以做，所以select正确的工具可能不是那么简单。
我希望这是外行人的条款，并有助于你的理解。
大部分你“知道”是错误的。
首先，正如一些关系专家经常（有时候会很快地）指出的那样，SQL并不像许多人想象的那样与关系理论的关系差不多。 其次，“NoSQL”中的大部分差异与关系与否无关。 最后，要说“NoSQL”和SQL有什么不同，因为它们代表了相当广泛的可能性。
可以指望的一个主要区别是，几乎所有支持SQL的东西都支持数据库本身的触发器 – 也就是说，可以将规则devise到数据库本身中，以确保数据始终保持内部一致。 例如，你可以设置一些东西，让你的数据库声明一个人必须有一个地址。 如果你这样做，任何时候你添加一个人，这基本上会迫使你把这个人与某个地址联系起来。 您可能会添加一个新地址，或者您可能会将其与某个现有地址相关联，但无论如何，该人员必须拥有一个地址。 同样，如果您删除地址，则会强制您删除当前位于该地址的所有人员，或将每个人员与其他地址关联。 你可以为其他关系做同样的事情，比如说每个人都必须有一个母亲，每个办公室都必须有一个电话号码等等。
请注意，这些东西也保证以primefaces方式发生，所以如果其他人在添加该人时查看数据库，他们将根本看不到该人，否则他们将看到具有地址（或母亲等）
大部分的NoSQL数据库不会试图在数据库中提供这种强制执行。 在使用数据库的代码中，由您来执行您的数据所需的任何关系。 在大多数情况下，也可以看到只有部分正确的数据，所以即使你有一个家庭树，其中每个人都应该与父母关联，但是有时候不pipe你施加的限制是不是真的强制执行。 有些人会让你随意做。 其他人则保证这只会暂时发生，尽pipe究竟能持续多久可以持续下去。
关系数据库使用谓词的正式系统来处理数据。 基本的物理实现没有任何实质内容，可以根据某些操作进行优化，但必须始终采用关系模型 。 通俗地说， 我只是说我知道我的表（关系）中每一行（元组）有多less个值（属性），现在我想要相应地彻底地利用这个事实，并且是极端的。 这是野兽的本质。
因为我们显然是有关系成长的一代，所以如果从关系模型的angular度来看NoSQL数据库模型，再次从外行人的angular度来看，第一个明显的区别就是没有关于行数值的假设包含有史以来。 这实在是把事情简单化了，并没有把每个NoSQL数据库的物理模型错综复杂地加以应用，但它是关系模型的顶峰，也是我们必须留下的第一个假设，或者，如果你愿意的话，最大的我们必须飞跃。
我们可以同意两个对于每个DBMS都是正确的东西：它可以存储任何types的数据，并有足够的math基础来使得以任何可以想象的方式pipe理数据成为可能。 现实情况是，你永远不会想把两个要点中的任何一个都考虑进去，而只是坚持真正的DBMS的真正目标。 用外行的话说： 尊重内心的野兽！
（请注意，我已经避免将围绕关系模型的（明显）标准化的标准与NoSQL数据库提供的许多标准进行比较，如果您愿意，可以将NoSQL数据库视为任何不完全DBMS的总称假定关系模型排除在外，差别太多了，但这是主要的区别，而且我认为这两者之间的区别最为明显）。
尝试用一点技术来解释这个问题
以MongoDB和传统SQL进行比较，想象一下在Twitter上发布Tweet的情况。 这个推文包含9张照片。 你如何存储这个鸣叫和相应的图片？
就传统关系SQL而言，您可以将推文和图片存储在单独的表中，并通过构build新表来表示连接。
另外，您可以设置一个图片types的字段，将9张图片压缩成二进制文档并存储在这个字段中。
使用MongoDB，你可以像这样构build一个文档（类似于关系型SQL中的表的概念）：
{ "id":"XXX", "user":"XXX", "date":"xxxx-xx-xx", "content":{ "text":"XXXX", "picture":["p1.png","p2.png","p3.png"] } 因此，在我看来，主要区别在于你如何存储数据和它们之间关系的存储级别。
在这个例子中，数据是推特和图片。 它们之间存储关系的不同机制也在二者之间的差异中起着重要的作用。
我希望这个小例子有助于显示SQL和NoSQL（ACID和BASE）的区别。
下面是从互联网上关于NoSQL目标的图片链接：
关系和非关系的区别正是这一点。 关系数据库体系结构提供了约束对象，例如主键，外键等，允许将关系中的两个或多个表绑定在一起。 这很好，所以我们将我们的表格规范化，即将数据库代表的信息分割成许多不同的表格，一次可以保持数据的完整性。
例如，假设您有一系列的表格，其中包含关于员工的信息。 不能删除表中的logging，也不能从其他表中删除与此类logging相关的所有logging。 这样你就可以实现数据完整性。 非关系数据库不提供这个约束结构，这将允许您实现数据完整性。
除非你在用来填充数据库表的前端应用程序中没有实现这个约束，否则你正在实现一个可以与狂野西部进行比较的混乱。
;){kind=link}