1.预设计模式与动态模式

传统数据库设计思维中，项目的设计阶段需要对数据库表中的字段名称、字段类型、进行规定，如果尝试插入不符合设计的数据，数据库不会接受这条数据以保证数据的完整性。

NoSQL采用的是对集合(类似”表”)中的文档(类似于”行”)进行动态追加，在创建集合之初不会对数据类型进行限定，任何文档都可以追加到任何集合中去，例如我们可以将这样两条文档添加到一个集合中去：

MongoDB中文档的格式类似于我们常见的JSON，由此可见，我们第一个拥有”name”、”song”两个字段，而第二个拥有”name”、”age”、”email”三个字段，这在预设计模式中的数据库是不可能插入成功的，但在MongoDB的动态模式是可以的，这样做的优势是我们不必为一些数量很少，但种类很多的字段单独设计一张表，可以将他们集中在单独一张表进行存储，但这样做的弊病也是显而易见的，我们在获取数据时需要对同一张表的不同文档进行区分，增加了开发上的代码量。所以在设计之初需要权衡动态模式的优劣来选择表中的数据类型。

2.范式化与反范式化

范式化(normalization)是关系模型的发明者埃德加·科德于1970年提出这一概念，范式化会将数据分散到不同的表中，利用关系模型进行关联，由此带来的优点是，在后期进行修改时，不会影响到与其关联的数据，仅对自身修改即可完成。

反范式化(denormalization)是针对范式化提出的相反理念，反范式化会将当前文档的数据集中存放在本表中，而不会采用拆分的方式进行存储。

范式化和反范式化之间不存在优劣的问题，范式化的好处是可以在我们写入、修改、删除时的提供更高性能，而反范式化可以提高我们在查询时的性能。当然NoSQL中是不存在关联查询的，以此提高查询性能，但我们依旧可以以在表中存储关联表ID的方式进行范式化。但由此可见，NoSQL的理念中反范式化的地位是大于范式化的。

MongoDB还年轻

MongoDB又有众多卓越的设计，但MongoDB依然存在着许多不擅长的问题，其中包括：

1. MongoDB不支持事务，现在众多的软件依旧需要事务的管理，所以对于事务一致性要求较高的程序只能在软件层面进行管理，而无法从数据库进行管理。

2. 其他工具的支持范围，MongoDB从发布起到现在还不到5年的时间，所以会面临着许多的语言没有对应的工具包，所以如果你使用的语言没有对应的包，可能是导致你无法使用MongoDB最大的阻碍。

3. 社区的资源量，这个问题同第二个问题一样是因为MongoDB过于年轻导致的，相对于其他大型数据库的社区而言，MongoDB显然是无法与之相比的，然而社区往往也是一个重要考量因素之一，社区资源的匮乏会导致问题解决周期延长，从而拖延工作。

近几年的技术发展之快是激动人心的，每年都会出现让人眼前一亮的产品，然而它都需要经过时间的累积才能成为一个成熟的产品，MongoDB还需要成长，但他优秀的设计，肯定会让越来越多的开发者接受它。