MongoDb 相比于传统的 SQL 关系型数据库，最大的不同在于它们的模式设计（ Schema Design ）上的差别，正是由于这一层次的差别衍生出其它各方面的不同。
我们可以简单的认为关系型数据库由数据库、表（table）、记录（record）三个层次概念组成，而在构建一个关系型数据库的时候，工作重点和难点都在数据库表的划分与组织上。一般而言，为了平衡提高存取效率与减少数据冗余之间的矛盾，设计的数据库表都会尽量满足所谓的第三范式。相对的，可以认为MongoDb由数据库、集合（collection）、文档对象（Document-oriented、BSON）三个层次组成。MongoDb里的collection对应于关系型数据库里的表。当然，不要期望collection会满足所谓的第三范式，因为它们根本就不在同一个概念讨论之内。类似于表由多条记录组成，集合也包含多个文档对象，虽然说一般情况下，同一个集合内的文档对象具有相同的格式定义，但这并不是必须的，即MongoDb的数据模式是*的（schema-free、模式*、无模式）。
以一实例来说，假设我们需要设计一个小型数据库来存储“学生、地址、科目、成绩”这些信息，那么关系型数据库的设计如图1所示，而Key-value型数据库的设计则可能如图2所示。
图1、关系型的数据库设计
图2、Key-value型的数据库设计（直接借用的mongodb官方图）
对比图1和图2，在关系型的数据库设计里划分出了4个表，而在Key-value型的数据库设计里却只有两个集合。如果说集合与表一一对应的话，那么图2中应该也有4个集合才对，为什么可以把本应该是集合的address和scores直接合入了集合students中？原因就在于在Key-value型的数据库里，数据模式是*的。
以scores来说，在关系型的数据库设计中将其单独成一个表是因为student与score是一对多的关系，如果将score合入student表，那么就必须预留最多可能的字段，这会存在浪费，并且当以后新增一门课程时扩展困难，因此一般都会将score表单独出来。而对于Key-value型的数据库就不同了，其scores字段就是一个BSON，该BSON可以只有一个for_course，也可以有两个、三个、任意个for_course，其固有的模式*特性使得它可以将score包含在内而无需另建一个score集合。
对于与student为一对一关系的address表也可以直接合入student，无需担心address的扩展性，当以后需要给address新增一个province字段，直接在数据插入时加上这个值即可。
当然，对于与student成多对多关系course表，为了减少数据冗余，可以将course建立为一个集合，同关系型的数据库设计中类似。
对比于关系型的数据库，在Key-value型的数据库里将数据合入一起有几大好处：首先，数据检索时没有了进行表间连接（join）的巨大开销（虽然目前MongoDb中没有join的概念）；其次，合入一起的数据在磁盘上的存放也更容易在一起，因此数据的读取/写入都更快速。另外，无需担心扩展性问题，Key-value型数据库的自身特性使得字段的增删改十分容易。