1.4 关系数据库技术的局限性
传统的关系数据库技术假设数据具有很强的结构化特征。关系数据库所存储的数据特点可归纳为如下几点：
1）结构统一。关系中的数据具有相同的结构（模式），具有很强的格式化特点。
2）面向记录。在关系数据库中，对于用户而言，数据库是一个记录的集合，所有数据都是以记录的形式存在的。
3）数据小。关系数据库中的记录一般都比较短。
4）原子属性。关系数据库中的每个属性值都是无结构的，是不可分的原子值，满足1NF定义。
随着计算机技术的不断发展，一些新的应用开始出现，例如GIS、多媒体、超媒体、CAD等。这些新型应用中的数据大都不具备传统的数据特征，因此，使用传统的关系数据库技术来表达和存储这些新型数据就遇到了困难。例如，在关系数据库中如果要存储一段视频，现有的做法只能将视频作为BLOB（大二进制对象）存储在关系数据库的某个字段中。但是，视频上的一些操作，例如快进、后退、片段截取等，在SQL语言中难以得到支持。而且BLOB数据也无法使用传统的SQL语言进行操作（Insert、Update等），必须借助其他方法才能实现。因此，虽然关系数据库技术能够支持新型复杂数据的存储，但很难有效地支持对这些复杂数据的操作，更不用说支持其他的功能了，例如复杂数据的索引、查询优化等。
另外，关系数据库技术在数据表达方面也存在低效的问题。根据关系数据模型，现实世界中的实体对应着关系中的一个元组，但是1NF的要求容易导致关系中出现冗余数据。例如图1-11所示的一个图书关系的例子，由于1NF要求属性值必须是不可分的原子值，因此出现了很多冗余的属性值。
图1-11 关系数据库的1NF要求导致属性值冗余
按照关系数据库的规范化技术，可以将图1-11所示的关系模式分解为三个关系模式，从而减少冗余，优化模式设计。规范化模式分解的结果如图1-12所示。
图1-12 规范化模式分解的结果
模式分解结果虽然解决了冗余表达的问题，但仍然存在以下问题：
1）一本书在现实世界中是一个独立对象，而在图1-12所示的数据库设计中被人为地分割成了几个关系。也就是说，关系数据模型不得不通过多个实体集（关系）来表达现实世界中的一类实体（见图1-13）。
图1-13 现实世界与关系数据模型之间的认知鸿沟
2）不能表达作者之间的顺序关系。
3）SQL可以执行分组操作，但只能返回单个的聚集函数值，不能返回一组结果。例如不能实现查询所有作者及其所写作的书列表。
关系数据库技术的局限性还表现在缺乏对Web 2.0应用的有效支持方面。对于微博、微信等Web 2.0应用而言，关系数据库的很多主要特性往往无用武之地，主要表现在：
（1）数据库事务一致性需求
很多Web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此，数据库事务管理成了数据库高负载下一个沉重的负担。
（2）无法满足海量数据的管理需求
关系数据库解决海量数据存取的主要手段是索引、缓存等技术，但在Web应用尤其是Web 2.0应用中，数据量往往以PB计算。面对如此海量的数据，关系数据库系统的传统优化技术往往难以取得理想的性能。目前一般的理解是，一个关系数据库的基本表中的记录数一般不能超过一千万条，否则性能就很难保证，需要人工分库分表。虽然MySQL等也提供了数据库集群的支持，但是关系数据库集群部署和配置复杂，主备之间备份和恢复不方便，动态扩容能力弱，而且动态数据迁移难以实现自动化。
（3）对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的Web系统都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的SQL报表查询，特别是SNS类型的网站，从需求及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大地弱化了。
（4）“One size fits all”模式很难适用于截然不同的业务场景
关系数据库技术的核心思想是“统一”，即使用一个数据模型和一个数据库统一存储和管理所有的数据并且支持所有的应用。这种“One size fits all”的思路在互联网时代很难适应快速发展的应用模式。例如，联机数据分析（online analytical processing，OLAP）和联机事务处理（online transaction processing，OLTP）这两类应用一个强调高吞吐、一个强调低延时，已经演化出完全不同的架构，使用同一套模型来抽象显然是不合适的。