由代码生成数据库结构，保障设计正常传递到实现

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>>

我们常常使用代码生成工具来生成表结构。为什么不试试从代码来生成数据库表结构呢？

这个观点有些匪夷所思，但是熟悉Hibernate的同志应该有所体会。Hibernate有一个功能，叫做hbm2ddl,在系统启动时，Hibernate扫描hbm映射文件，检查数据库结构和hbm是否匹配，如果不匹配，则在数据库中增加hbm文件中描述的表或者字段。严格意义上来说，这不是从“代码”生成表结构，而是由“hbm配置文件”生成表结构。后来，当Hibernate支持注解功能后，hbm2ddl也会自动扫描EntityBean上的注解，来与数据库表结构进行匹配。所以，这个hbm2ddl，也算作从代码生成表结构。

回到原点，为什么需要从代码生成表结构的功能？

我们一般的开发过程，是先做了“数据库设计”，然后在数据库中建表，最后再编写java代码。数据库设计工具，一般提供生成表结构到数据库的功能，也提供生成和表结构对应的javabean功能。

【数据库】<-【数据库设计工具】->【JavaBean】

如果我们的数据库一次成型，永不改变，每个版本只做代码层面业务逻辑上的变动，那么上面的过程是比较完美的。

但实际上，作为一个长期维护的软件系统，数据库设计不变动，是几乎不可能的。那么，当开发下一个版本的时候，我们首先需要变动的是数据库设计文件，然后在开发环境中，变更表结构，然后在源代码中，变更JavaBean的定义。

假设我们用到的数据库设计工具非常好,那么我们可以用它对比新的设计文件和旧的数据库结构及代码的差异来达到设计与实现同步的目的：往数据库方向，能增加表和字段，往JavaBean方向，能加入新的类和属性。

到了测试/发布的环节，代码可以从代码库中下载打包，到达测试/最终用户的手里。数据库表结构的变动，如何到达测试/正式环境？

其中的一个解决办法，就是将数据库设计文件也打包到软件发布包中，发布新版软件时，用数据库设计工具把最新设计文件，体现到新环境的数据库中。但是发布新版本还要拽着先进的数据库设计工具，很少有公司这么做。

Hibernate支持这种方案的变种，我们可以从数据库设计文件生成 hbm文件（我们把hbm文件当做数据库设计文件的另一种表现），它随着新代码一同发布到新的环境中，在启动时，Hibernate就会依据hbm文件把数据库的变更应用到新的数据库环境中。

非Hibernate体系如何做？遥想当年EJB2.0时代，每次变更完数据库设计文件（当然，我们项目组人多的时候，往往都不变更数据库设计文件，直接在数据库里面改了），要手工把数据库变动的DDL语句转存成sql脚本文件（入代码库）。“入代码库”四个字打上括号，是因为项目组人数多的时候，总有人忘记上传自己的脚本。等到总体发布测试环境的时候，手忙脚乱，A少入库了sql脚本，B搞错了sql脚本的执行顺序。等到交付用户的时候，又会发现，当初紧急修改的内容，数据库结构是改了，数据库设计文件没有改。

纵观上面的过程，其实我们发现要维护：设计文件、代码、数据库三者的同步。如果我们以设计文件为核心，那么，设计文件和开发环境的代码同步还好处理，在发布阶段，设计文件和测试/生产环境的数据库结构就难同步了:一则除了powerdesigner（广告）外，我们确实没有特别好的工具做这种同步，二则使用手工脚本的办法太容易出错了，三则不是所有的项目都用Hibernate。

如果，设计阶段，我们维护设计文件，开发阶段，由设计文件和代码同步，在发布阶段，再由代码和数据库结构同步，就摆脱了设计文件直接同步到测试/生产数据库这种尴尬的情况了。让我们的JavaBean中，存储上数据库的信息，是不是会好一点？

@Table (name = "st_user")

public class User {

/** 账号 */

@Column (length = 64, nullable = false, unique = true)

private String account;

/** 密码 */

@Column (length = 64)

private String password;

}

假设上面这个JavaBean是我们用数据库设计工具，从数据库设计文件生成的,它带了一些数据库层面的信息（table_name,column_length等），那么正好可以在系统启动阶段，验证正在使用的数据库是否和设计匹配，如果不匹配，我们也可以做对表结构做一些更改，使之符合设计要求。

我们发布的时候，既不用发布设计文件，也就不必带着那些ddl了，我们的bean早就洞悉了一切。