应用hibernate通过对象模型创建表和表关系后数据库表扩展问题

看到个数据库表维护及扩展问题,使用的是pureXML技术完成。当然我没接触过这个技术,具体如何实施和使用不太了解。
如果一般情况下,可能现在还是大多数项目的设计还是从数据库设计开始,表,表结构,表关系等等,然后设计生成OO模型等。(应该是这样吧?)
虽然我以前接触的项目也是这样生成的(设计数据库,表等等,然后用hibernate生成对应的实体模型,这样),但是通过对OO的学习,以及OOA,OOD,OOP等这些的了解,自己的思想里更多的还是偏向先根据项目的业务需求设计实体模型,属性,以及实体和实体之间的关系等等,最后通过hibernate生成相对应的表,表关系这些。
但是突然想到个问题。信息系统交付使用之初,数据库表结构的设计往往逻辑结构清晰,管理使用方便,但是当信息系统项目运行一段时间,随着业务的不断变化和增加,处理流程不断的变革,信息系统需要从前台界面到后台数据库的完善和修改,势必要对数据库表结构必须要进行扩展。
那这样的话我们一般如何处理呢?当然前提肯定是有环境和上下文的。(项目的大小,需要改动的字段,关系的多少等等这些问题)。是通过修改实体模型呢,还是修改数据库呢?当然可能也有用到上边的pureXML技术还有很多别的技术解决的。但是我问的还是:是通过修改实体模型呢,还是修改数据库哪个更多或者说更适合呢?
实际还没接触这个问题,也可能这也算是个技术领域方面的问题。问的不知道对不对,希望大家给些意见和指正。谢谢!

LZ描述的开发环境里面通常都有一个特定的前提:数据库结构,这是发包方已经指定的环境,通常不是我们可以修改的内容。在这样的前提下进行系统整合的时候核心问题之一已经是数据库结构了。

此时需要从2个方面下手:
1.从业务过程开始分析,总结所需要的数据
2.从数据库着手,进行适当的修改以满足当前业务发展需求
总之此时技术不是关键问题,因为你已经不可能进行数据库重建了。

如果是新系统,采用hibernate生成数据库结构。
但是以后业务变化,是重新生成机构还是人为修改数据库?人为修改数据库如何保持系统OO设计的一致?