wlcome998

自从有了rake之后
改数据库逻辑已经不是难事了
不用求DBA了,
所以不从数据库开始设计是必然的事

从我做的实际项目（项目数>10）开发来看，从来没有一个项目的数据库是完美的，总是在修修补补，据我的了解，其他的项目也大抵如此，那么使用Hibernate开发的话应当如何设计？

谢谢大家的讨论，最近偶然看到一本外文书，大致和楼上的表达的思想很接近，作者是参与Hibernate设计的开发人员，书中也对这设计的方式进行了讨论，作者就认为没有一成不变的设计方式，要根据具体的情况来做具体的设计方式，归纳为三种
1.POJO-Driven Approach
In the POJO-driven approach you start with an object/domain model, and using JSR-220 annotation or Javadoc metadata comments, you define how each field in a class maps to a database column. At runtime, Hibernate uses the annotations to dynamically create the mappings.
这种方法适用于数据模型还没创建和设计或者不明确的新应用程序
2.Data Model–Driven Approach
In the model-driven approach you start with a database schema for the chosen database system, and using a tool like Middlegen or Hibernate Synchronizer, you generate mappings and POJOs for each table being mapped. This approach provides a fast start-up time for development。
这种适合已建立明确的数据库或者数据模型的web开发，并能快速的开发。
但也指出使用这种设计的方式会造成域模型的semantic(语义)不够丰富，达不到你原先设想的那样。
3. 作者自己推荐的是一种是第三种方式，称为HBM-Driven Approach。
The two previous approaches, taking either a domain-model or data-model approach, typically result in HBM mappings that are not quite complete. Every time I use either of the approaches above in a moderately complex application, I find myself fine-tuning the HBM files to either
get more accurate POJOs (in the data-driven approach) or more efficient, manageable database
schema (in the POJO-driven approach). The third approach suggested here takes the stand that object-relational mapping is an inescapable, necessary evil that should be taken into consideration early and in a head-first fashion in the development of your application.By
creating detailed, accurate HBM files you will end up with both a domain model and a database schema that meets your application needs and ensures the longevity of the data

千万不要首先就考虑数据怎么存储

理清业务，搞清域，再适当考虑怎样存储就可以了
说白了就是首先要逻辑上没有问题再来实际的

如果需求都未搞清楚，来谈对需求的持久化那不是白搭
反过来如果业务模型搞清楚了，逻辑上无问题了，那存储实际上基本上已经定好了，剩下的就是存储细节和性能了

至于先后顺序楼上有人说得蛮好的，看习惯了，无论哪种方式，都会需要微调的

无论怎么样我们都需要搞清业务模型才能够去设计数据库，千万别从数据库入手来设计业务了，我目前所在的系统在扩展性和响应需求的时候就遇到了当初数据库设计的瓶颈了，现在数据到处都有，一片混乱，明年可能会全面整合业务了

我个人比较喜欢先建立实体模型,再根据实体模型来推数据库,然后在项目的进行过程中,如果业务变动,随时使用变动后的实体模型,同步升级数据库.当然,你说有一些初始化的测试数据,可以用其它方式加载.

有时对于一个相同的关系模型，可能会在数据库中建立不同的表结构，（取决于性能）所以建议在OO的开发过程中先关系后库。

项目中不关心数据库模型

一般清楚需求理清层次,后用ppt做表现层反映需求, 然后再建立数据库模型来反映表现层.

比较同意楼上的意见 我也个人比较倾向于这种观点。。如果当关联关系过多的时候，也不妨优先考虑从域模型入手，因为ORM映射最终是需要域模型和关系模型保持对应，消除阻抗。。

我倒是觉得先建库还是先建Hibernate对象都可以，看团队比较习惯那种方式，毕竟最后都要达到两者一致
如果觉得某种方法麻烦，完全可以调整为另一种方法嘛

我觉得还应该是先建立关系,然后用工具生成hibernate的配置文件

我是先建数据库,关系也弄好,然后用工具自动生成

你这里的数据模型是个什么概念呢 呵呵，怎么样抽象成数据模型？

我通常是先建立数据模型，然后由hibernate帮我自动建立数据库。当然，也要根据实际情况，对自动生成的数据库进行一下微调，建索引之类的，优化一下数据库。