【IT168 应用】数据的存取几乎可以说是所有应用程序都会涉及的话题。
针对在主存储器中处理数据的存取，我们从数据结构的教材上学到许多数据结构，像是linked list、hash table、tree、……等等。每种数据结构都有它的用途，针对不同的目的及操作，也都会在时间、空间效率上展现出不同的特性。而优秀的程序设计者也都多半能熟练的掌握这些不同的数据结构，将它们运用在合适的地方。
关联式数据库的兴起，使开发人员不像过去经常自己设计文件结构
然而，对大多数的程序而言，不仅只会在主存储器中操作、存取数据，另一方面，由于主存储器容量有限、而且无法永续存储数据的关系，程序还是会有将数据存储在具永久性和连续性存储能力之文件系统上的需要。
而当将数据存储在文件系统，基于各种不同的应用及需求，所衍生出来的话题十分繁多。在多年前，许多程序设计者甚至会在文件系统中自己设计用来存储数据的文件结构，以满足自身程序的需求。当然，在信息科学的研究中，也有各种文件结构用来提供数据应用程序之所需。就和在主存储器中运用数据结构一样，程序设计者也会针对各种文件结构的特性，妥善运用各种文件结构。
不过，这样的现象在关联式数据库逐渐普及之后，由于关联式数据库的威力强大、可以涵盖各种应用，对于应用程序中所需的各种操作，也都足以应付。
关联式数据库技术精进，不论是在数据量、存取效率、稳定性、容错能力等，都让多数程序设计者得到大大地满足。
慢慢的，在很大比例的应用程序开发中，几乎都采用关联式数据库技术来做为永续性的数据存储方案，这说明了关联式数据库技术的普及程度、以及受到程序设计者的喜爱程度。但最后，这似乎成了一个既定的刻板印象及想法，甚至构成了一个思路的陷阱，当程序设计者打算将数据存储起来的时候，几乎都会直接联想到关联式数据库。不论什么样类型的数据，都把它们一笔笔地往关联式数据库里丢。
正因为关联式数据库太强大、能应用的范围也很广泛，所以运用它来解决永续性的数据存储，可以说是十分的便利，在一般的情境下，也都能胜任。不过，这么一来，也很容易建立起程序设计者对它的依赖。
不少程序设计者对于其他永续性数据存储方案的运用能力，似乎都退化了不少。刚入行的程序设计者甚至不懂得、或者是不熟悉如何运用其他永续性的数据存储方案。在一般承平时期，关联式数据库足堪应付时，这样的情况还不至于造成太大的问题。但是，倘若碰上了障碍，也就是关联式数据库本身不那么适合处理的应用时，有些程序设计者，反而不知道该如何面对这样的障碍。
事实上，有时候改用不同的存储方案来处理特定的问题，反而会比千篇一律地采用关联式数据库来得适合。
关联式数据库也有不适合应用的时候
举例来说，有些时候，我们要存取的数据，每笔数据都有固定的地址，但是，这些地址不会需要和其他数据的地址交互关联，也只有一个键值。而在应用程序中，只需要新增数据、指定键值对数据进行查询及删除。针对这个应用，当然，你可以在关联式数据库中建立一个数据表，然后利用这个表格来存储这样的数据。强大的关联式数据库要处理这样的数据当然不成问题，数据很单纯、需要的操作也很单纯。
正因为其实要面对的问题很单纯，但使用的工具很强大，就成了杀鸡用了牛刀的局面。牛刀能杀牛，但用来杀鸡就显得有点不称手。当你用强大的关联式数据库来处理需求很简单的数据时，强大的威力反而变成了绊脚石。
关联式数据库的设计，是为了要满足各种复杂的关联式查询及数据处理，因此，在机制上自然是相当的复杂。而在这样复杂的机制下，去处理简单的数据，即使数据本身再怎么简单，在效率上也会大打折扣。
如果你的应用程序大多数的操作是依据主键值，查出对应的该笔数据，你当然可以执行一个SQL查询的动作，把对应的数据查询出来，这对威力强大的关联式数据库而言，根本是探囊取物一般。可是，即使是这样简单的查询，遇到庞大的数据量时，这个查询还是会耗费不少时间。
这并不是牛刀不够厉害，而是牛刀有该用牛刀的地方。
针对这样的应用，你也可以改用像Berkeley DB之类的解决方案。
Berkeley DB不像典型的关联式数据库那样强大，当然就不那么的复杂。处理起这样的数据，可以说是适得其所，而且更为高效。
这正是许多程序设计者目前在永续性数据处理上的一个盲点。
因为关联式数据库搭配SQL语言的强大，让程序设计者过度依赖关联式数据库，反而失去了运用其他类型数据管理方案的能力。倘若只局限在关联式数据库的基础上，而又遭遇了效能问题，想要加以调校以提升效能，就得大费手段。但是，若能跳脱只能在关联式数据库的基础上解决这个问题的限制，反而容易多了。
混合运用其他数据存取方式的可能性会增加
可以想见的，关联式数据库依然会是一个主要的数据存储平台，但是，针对特定类型、特定需要的数据操作，我们可能会混用其他较关联式数据库更适合的数据管理方案。
最近许多人在谈所谓的NoSQL数据存储方案，当然这NoSQL字面上的意思是代表非SQL语言，不过本质上指的其实是非关联式的数据库。我观察到，大多数会开始采用NoSQL方案的开发者，基本上都是因为数据规模的关系。
关联式数据库很好用，但它不容易扩展到很大的规模。因此，许多开发者逐渐开始运用所谓NoSQL数据库来存储所谓“海量”的数据，而一些云端计算平台，也都以此类的数据存储方案，来做为平台供应用程序处理数据的机制，都是为了面对大规模的数据量所做的应对。
而且，许多NoSQL的方案都提供分散式的机制，允许将大批机器的计算能力及存储能力群集起来，提供允许超大规模的数据高效存取。
当然，本文的主旨并不在说NoSQL的卓越及关联式数据库的落伍，而是试着提醒，数据存储及处理是应用程序中的重要操作，关联式数据库固然强大，但内部复杂的运作方式，也构成了一些本质上难以突破的先天障碍。
我们或许已经习惯于总是将数据都交给关联式数据库来承载，而忽略了应该针对数据本身及所需操作的特性进行分析，进而在适当的时机，选用关联式数据库之外的方案来处理数据。你或许不会需要用到处理海量级的分散式NoSQL方案，你有可能选择的是像Berkeley DB之类轻薄短小的数据库，端视你的需求而定。甚至你可以自己设计自己的数据存储机制。
