在关系数据库和文档数据库的对比中，我们通常考虑他们各自拥有下面的优点：
- 支持文档数据模型的主要论点是模式灵活性，由于局部性它会带来更好的性能，对于某些应用来说更接近应用程序所使用的数据结构。
- 支持关系数据模型的主要论点是它在联结操作上的支持，多对一和多对多关系的简洁表达。
首先需要明确的是，我们无法一概而论地说哪种数据模型地应用代码最简单，这主要取决于数据项之间关系类型。
- 如果应用程序具有类似文档的结构（即一对多关系树），那么使用文档模型最为合适。
- 这种情况下使用关系模型会将原本简单的问题复杂化。
- 文档模型描述文档结构时也有一定的局限性，比如他们不能直接引用文档中的嵌套项。而必须使用“用户xxx地职位列表中的第二项”，这样的语句描述。
- 如果应用程序不需要多对多关系或多对一关系，文档数据库对联结支持不足就天生地不是一个问题。
- 如果应用程序确实使用了多对多关系，那么应当使用关系模型。
- 使用文档模型也不是没有处理联结关系的办法，比如发送多个请求，在应用代码中模拟联结。但通常这样做会使得系统代码更复杂，性能更差。
- 关系模型天然地更擅长描述多对多关系。
- 对于高度关联的数据，关系模型比文档模型更加优秀，但实际上图模型或许是最为自然的解决方案。
大多数文档数据库，以及关系数据库中的 JSON 支持，都不会对文档中的数据强制执行任何模式。没有模式意味着可以将任意键值对假如到文档中，并且读取时客户端无法保证文档可能包含哪些字段。
文档数据库中读数据的代码通常采用某种结构因而存在某种隐式模式，即我们所称的读时模式（数据的结构是隐式的，只有在读取时才解释）。与此相对的，关系模式的传统模式我们称为写时模式（模式是显示的，数据保证数据写入时必须遵循）。
下面给出一个例子，假如当前用户的全名存储在一个字段中，但现在想分别存储名字和姓氏：
-
在文档数据库中，我们只需使用新字段来编写新文档，并在应用层处理读取旧文档的情况
if(user && user.name && !user.first_name){ // 处理没有 first_name 的旧文档 user.first_name = user.name.split(" ")[0]; } -
在关系数据库中，我们通常需要对表结构进行更改
ALTER TABLE user ADD COLUMN First_name text; UPDATE users SET first_name = substring_index(name,' ', 1);实际上，大部分关系数据库在几秒内也可执行完上面的 ALTER 语句。除了 MySQL 在执行
ALTER TABLE时要把当前的整张表复制。至于第二步 UPDATE 语句，在大表上执行这个语句在任何数据库中都可能很慢，通常可以将
first_name设置为默认值NULL，在读取时填充它。
如果集合中的因为某些原因，不具有相同结构，例如：
- 有许多不同类型的对象，并且把每种类型的对象存在各自的表中不太现实。
- 数据的结构由无法控制的外部系统所决定，并且随时可能改变。
这些情况下，模式带来的损害可能大于他们带来的帮助。
3. 查询的数据局部性文档通常存储为编码为 JSON、XML 等形式的连续字符串。如果应用程序需要频繁访问整个文档（例如在网页上呈现）：则文档模式的存储局部性会带来性能优势。如果按照关系模式的做法，数据被划分在多个表中，则可能需要多次索引来检索所有数据，带来了更多的磁盘 IO，可能会影响性能。
局部性优势仅适用于需要同时访问文档大部分内容的场景。由于数据库通常会加载整个文档，如果应用只是访问其中的一部分，则可能会产生浪费。对文档进行更新时，通常会重写整个文档，而只有修改量不改变源文档大小时，原地覆盖更新才有效。因此通常建议文档应该尽量小并且避免写入时增加文档大小。
4. 文档数据库与关系数据库的融合近年来，几乎所有关系数据库系统都支持了 XML。包括对 XML 文档进行本地修改，在 XML 文档中进行索引和查询等。这样应用程序可以获得与文档数据库非常相似的数据模型。
PostgreSQL、MySQL 等数据库都对 JSON 文档提供了相应支持。
文档数据库方面，RethinkDB 的查询接口支持和关系型类似的联结，而一些 MongoDB 驱动程序可以自动解析数据库的引用关系（在客户端进行高效联结）。
融合两种模型是未来数据库发展的一条很好的途径。