本系列文章旨在记录和总结自己在Java Web开发之路上的知识点、经验、问题和思考，希望能帮助更多（Java）码农和想成为（Java）码农的人。

我们的租房网应用目前使用Spring MVC和Spring IoC，已经将展示层、模型层和控制器层进行了初步的分离（参考这篇文章）。

但是模型层使用的仍然是模拟数据，实际生产环境（就是部署到真正供用户访问的服务器，一般还有开发环境和测试环境）中肯定是使用真实数据，所以必须将一切数据都存储到数据库中（这里的数据库就是泛指可以永久保存数据的系统，比如文件系统、关系数据库、NoSQL数据库等，可以参考这篇文章）。

在Java中，主要使用JDBC（Java DataBase Connectivity，即Java数据库连接）来访问各种数据库，主要是关系数据库。

我们就使用JDBC来进一步解决租房网的数据持久化问题。不过，数据持久化问题不仅仅涉及持久化本身，还涉及数据持久化之后如何访问的问题。我将采用比较符合人的思维习惯的步骤来介绍这个过程。

下面的内容都是笔者自己的思考，不一定就正确或者适用，仅供读者朋友参考，也欢迎读者朋友批评指正。

数据库选型

首先，我们第一个想到的问题就是我们的数据要存在什么地方？

你可能会说，当然是硬盘上啊。这样回答也没有错，硬盘的确是当下主要的存储介质，不管是机械硬盘、固态硬盘、磁盘阵列。

然而，我们如果要直接编程操作存储介质那就太费劲了，于是人们发明了文件系统（也可以说是一种数据库管理系统）、数据库管理系统（可能是基于文件系统的），它们都提供相应的编程接口（即API），这样就能减轻数据库应用的编程负担。

但是，就目前来说，数据库分很多种，文件系统、关系数据库、NoSQL数据库等等，而每一种类又有很多具体的数据库产品，比如关系数据库就有Oracle、MySQL等等。我们到底要选择哪一种的哪一款产品呢？

嗯，这就是数据库选型的问题。它取决于下面的几个因素：

数据本身的特点，比如数据从哪产生的、产生的频率多大、产生的数据是什么内容，比如数字、文本、图片、视频、音频、地理位置等；有的数据可以描述一个个现实的实体对象，有的数据描述的是实体对象的行为或者实体对象之间的关系；有的数据可以形成流，有的数据可以形成树、图等结构。结构化、半结构化、非结构化这三个概念也是描述数据本身的特点的。事实上，结构化数据基本上可以等同于关系数据，即可以提炼出表及其各个列（即实体及其各个属性）。人们使用数据的特点，是一次写入数据后以后只读不再更新，还是需要不断更新该数据，新增数据的频率是多大，更新数据的频率是多大，每次读取、新增、更新的数据量是多少，数据的读写分布在某个局部范围还是均匀分布，是单条处理居多还是批量处理居多，访问聚合数据居多还是独立数据居多，是每个数据操作独立还是往往多个数据操作是一个整体，是同一个数据多个用户需要访问还是基本上一个数据就一个用户访问等等。数据库产品本身的许可类型（License）、价格、特性、性能、稳定性、部署是否容易、扩容成本、运维成本等。租房网应用的数据库选型

目前租房网应用的数据主要有两个，一个是用户数据，一个是房源数据。用户数据主要是通过用户注册添加的，但目前租房网应用并没有这个功能。房源数据也是用户发布而添加的，租房网应用同样还没有这个功能。

很明显，用户和房源很容易映射到现实中的实体，一个用户具有用户名和密码等属性，一个房源具有位置、房主、其他具体情况等静态信息（事实上，这些应该算是房产的属性，房产只有在需要出租出去的时候才成为房源，房源应该是房产的其中某种状态，但我们先不用搞这么复杂，就先这么统一对待吧），以及发布时间、发布者等动态/行为信息。

它们都是用户通过浏览器添加到我们的数据库中的，数据量应该也不会太大。后续的数据访问也主要是以读操作为主，短时间内访问量也不会太大。当然这个跟你对应用的定位有关，你如果希望应用迅速火爆起来，必然要实施各种营销和推广措施，这样的话短时间内数据量和访问量可能快速增长。

既然如此，我们完全可以采用关系数据库来解决数据的持久化问题。事实上，大多数Web应用都可以采用关系数据库，或者至少先拿关系数据库来尝试一下，那些所谓的大数据只存在于少数巨头互联网公司。

另外，开发环境和测试环境、生产环境的数据库应该不一样。在开发环境，我们最好选择不需要单独部署数据库服务器的数据库产品，否则，开发受限太多，既要部署数据库服务器，还受网络情况等影响，单元测试也不容易做。

测试环境和生产环境的数据库应该选择同款数据库才对。

所以，在租房网应用的开发环境中，我选择的是H2Database（可以参考这篇文章），直接在工程中添加它的一个JAR包即可。至于测试环境和生产环境，那就不作考虑了，毕竟它只是用来演示的，又不是真的要上线运营。

数据库设计

选定好了数据库，我们需要根据该数据库产品进行设计。

简单来说，对于关系数据库，我们就是要设计数据库中存在哪些表，每张表的各个列是什么，每个列的数据类型和约束是什么，是否要建立索引等等。

但事实上，要想进行数据库设计，一般先要对我们的业务、数据进行分析，实际上也属于需求分析的范畴。分析的方法也有很多，大家可以自行查阅相关资料。

当然，关系数据库的设计形成了比较系统的理论，什么关系模型、关系代数、关系演算、三范式、完整性约束等等，这里就不再赘述了。

当然，数据库设计可以采用文档工具记录下来，也可以采用所选定的数据库管理系统直接设计，也可以采用专业的第三方产品比如PowerDesigner等。

而设计也会有相应的方法论、理论、原则、规范等，这个也需要经过学习、实践、思考、总结等成长四步而沉淀到个人的，这里也不再赘述了。

一句话，方法论和工具都很重要。

租房网的数据库设计

至于我们的租房网，我们就继续采用简单、够用为原则，目前涉及到的数据就是用户数据和房源数据，那就设计用户表和房源表。

用户表设计三个列，一列是用户ID，一旦生成就不再变；一列是用户名；一列是密码。三个列都是字符串类型，但长度可以限制在某个固定长度，表的主键就是用户ID。实际上密码不能明文存储到数据库中，而是需要加密存储。

房源表也设计三个列吧，分别是房源ID、房源名称、房源详情，也都是字符串类型，但房源详情可以采用变长字符串，长度可以大一些，200、500都可以，但也不可过大，表的主键是房源ID。

这都是粗略的设计，仅用作演示我们开发基于数据库的应用是需要这么一步的，并不符合现实的需求，如果有需要，后面可以改进以符合现实的需求。

在测试环境和生产环境中，往往需要由数据库管理员（即DBA）来建立数据库、数据表，分配相应的权限，包括数据库用户名和密码，甚至是部署独立的数据库服务器。

在开发环境中，一般是采用嵌入式的数据库，建库、建表、添加测试数据等都是自己执行SQL脚本或编程来实现。

编写访问数据库的代码

这一步往往依赖于某个库。

在Java中，JDBC是最常用的数据库访问API，而它仅仅是个接口规范，实际上还需要具体某个支持JDBC的数据库产品提供的驱动包，它本质上就包含JDBC各个接口的实现类。

还记得这篇文章中提到的接口的作用和使用模式吗？

JDBC基本上也是遵从这种方式，上面的某个接口可以替换成JDBC中的某个接口，底下的实现类就是各个数据库厂商提供的驱动里面相应于该接口的某个实现类，上面使用该接口的外部程序就是我们的Web应用程序了，它仅仅使用JDBC接口而已，但实际运行时需要配置一个具体的数据库驱动（即JDBC的实现），这其实就是数据库驱动加载，后面再详细介绍。

当然，直接使用JDBC可能比较复杂，于是很多第三方厂商又将JDBC进行了封装，比如Spring就提供了JDBCTemplate来简化JDBC的操作，还有很多ORM（Object Relational Mapping，简称ORM，对象关系映射）框架也提供了某个方面的封装，这些以后再详细介绍。

下篇文章我们就初步使用JDBC来实现租房网应用的数据持久化吧。