[讨论贴]-----数据库设计流程（方案）讨论，畅所欲言

Question

     心里一直有点疑问想问一下各位大牛。
     在各位项目开始之前，设计阶段，设计数据库的时候。各位的设计流程是怎么样的？？     说说我矛盾的两种做法吧： A.  自顶向下（这种方式，采用hibernate时用的比较多）
    即，先设计实体，加上JPA标注，通过配置文件，生成数据库表。 B。自底向上
    即，先设计好数据库，再根据数据库来编写实体类，这种方式通常应该是不加JPA标注的吧？？
    甚至见过一些小的系统，采用这种方式设计数据库的时候，实体之间不关联起来，
    比如 PojoA 和PojoB是N：1的关系， 如果是关联起来的话，我们应该在PojoA里面定义一个PojoB的实例。而他们的做法是直接保存一个Integer PojoBId。即，直接把外键做为一个属性放实体里面。。 上次有一个做设计的朋友说，他现在做的项目就是两者都要设计，又要用JPA机制，又要用powerDesigner设计数据库。
这两者如何统一列？  个人感觉A做法比较适合稍微复杂一点的系统。B方案设计好数据库表以后再去设计实体，碰到复杂关系，是不是很难设置。第一：各位达人说一下自己设计数据库的时候的设计方案是怎么样的？？
第二：各位在设计实体的时候画UML类图吗？ 在设计流程的时候，画UML流程图吗？？欢迎畅所欲言

Answer 1

如果先设计数据库。。然后又采用JPA标注的话。。若是实体的某个地方设计与数据库有一点冲突，JPA应该会更改表结构吧？？？这个时候又如何处理？

Answer 2

hibernate.hbm2ddl.auto update 实体类发生变化,自动修改表结构

Answer 3

先使用 PowerDesigner 设计数据库，当然了，这个数据库在完稿之前是需要开会进行讨论、修改的，等全部完成之后再进行开发、生成实体什么的。整个数据库使用 PowerDesigner 生成的建表语句创建数据表、索引、序列什么的。开发进行中，不允许数据表结构做很大的改动，最多只能增加字段。

Answer 4

概要需求 >> 讨论会（可行性、交付物、费用时间预计） >> 数据库文档和详细设计文档 >> 评审会（设计是否符合需求，是否存在漏洞） >> 开发 >> 测试 >> 验收开发过程中发现问题就执行“评审会”步骤。

Answer 5

其实我有点小小的疑问，用PowerDesigner可以生成数据库方面的东东，
但是好像不能生成实体吧？？？？
实体要自己对照着数据库去建？？

Answer 6

与客户洽谈，确定需求（需求要尽善尽美的确立，日后碰到问题只能在解决）。数据库设计那一块我们用的ER Studio8.0

Answer 7

与客户洽谈，确定需求（需求要尽善尽美的确立，日后碰到问题只能在解决）。数据库设计那一块我们用的ER   Studio8.0

Answer 8

我用 JPA。如果是一个两个，我一般就自己写写代码了，如果有一堆的话，Eclipse JEE 自带个 Dali JPA 工具，或者使用 JBoss Tools 插件可以连接数据库生成 JPA 的 Entity 类的。

Answer 9

另外，我们对于有关联的数据表只建外建字段，不建外键引用，数据表的完整性引用依赖于程序代码。在大多数的情况下，ORM 实体不建立一对一、一对多或者是多对多的关联，就算在实体建了关联，也不创建任何级联操作。

Answer 10

Eclipse JEE 自带个 Dali JPA 工具，或者使用 JBoss Tools 插件可以连接数据库生成 JPA 的 Entity 类的。原来如此：
  一直不知道还有一个反向生成Entity类..呵呵 ，谢谢果子哥了。关于：我们对于有关联的数据表只建外建字段，不建外键引用，数据表的完整性引用依赖于程序代码。这句话，是不是可以这样理解：
现在有两张表：User (id,name...)  USER_DETAIL(detail_id ,user_id....)
我们在建立实体user_detai的时候,
只会建立一个Integer user_id属性；而不会建立一个 User use的属性？但是我们在JPA机制里面在生成的实体一般机制都是后者,即建立一个User user属性，把两者关联起来。
只不过是把fetch=lazy
从这两点上看，这两种是不是在思想上不统一列？

Answer 11

火龙果大牛的意思是 只建外键, 但不加约束, 让程序去控制A表里的外键   就是B表里面的主键现在我所在的公司数据库我来设计, 我开始就打算直接搞出实体类, hibernate直接生成就完了可是头儿说要给出表结构图, 我只有先用powerdesigner画出来了, 然后对应的实体类里面, 我还是比如 PojoA 和PojoB是N：1的关系， 如果是关联起来的话，我在PojoA里面定义一个PojoB的实例(而不是PojoB的id)

Answer 12

对于主键列的命名，我不管是什么表，主键列都叫 ID，呵呵至于关联那个，这要看准备怎么用了。对于 USER 和 USER_DETAIL 表的话，使用 USER_DETAIL 在大多数时候不需要知道 USER 的数据，这样可能你会使用 FetchType.LAZY，在用到时现查，试想，这样与使用 USER 的 ID 直接查有什么区别？为什么全自动的 ORM 工具，在效率上要比半自动的 ORM 工具要差，在关联处理上是一点。全自动的 ORM 工具，只要一关联一般就得把关联表所有的字段全部查出来，哪怕我们只要用到一个字段。

Answer 13

我不知道 Hibernate 现在是怎么处理这样的 SQL 语句的：DELETE FROM t_user t WHERE t.status = 0;原来版本的 Hibernate 是这样处理的：先将这个条件的 t_user 记录查出来，然后再一个一个地删掉，我简直要蹶倒！

Answer 14

谢谢果子哥和jiushu2009
现在明了很多了。。  顺便问一句果子哥，有没有什么比较好数据库设计方面的书或者资料。
还是这东西，完全靠经验积累?

Answer 15

所谓自顶向下和自底向上，不过是
拿螺丝上螺母和拿螺母上螺丝的问题，
哪边能动就上哪边。
上到位就行了。
见笑了。各位谈到的经验值得收录。谢了。
Mark