我是不留,因为有的要测试向一个表里添加数据,因为外键的关系,可能先要向别的N个表里添加完数据才可以,很麻烦。
大家留不留关系?

解决方案 »

  1.   

    还有,有没有MYSQL的可视化的画关系的工具?就像sql server那样的?
      

  2.   

    1. 留关系比较好,这样可以很好地维护数据的引用完整性,楼主所说的直接在数据库中进行数据操作的情况并不多,大多数都是在信息系统中来进行。
    2. MySQL也有的,你找找就可以找到。
      

  3.   

    1.不留关系,数据库只做持久,ORM仅做ORM。我个人的推荐是甚至在Model层都不做关系的,更何况在关系数据库的表之间,只会增加耦合。2.MySql的客户端程序有很多。搜索下就可以。不过我还是比较钟情于phpmyadmin,网页客户端比较方便而且功能上也很强大。
      

  4.   

    不太认同仁兄的见解,其实建不建关系都各有优点
    建关系太麻烦,而且建好了关系了,如果程序里添加了一个数据是另一个外键表里没有的数据,又报了SQL异常。。但是如果建了关系,虽然是麻烦了一些,但是能保证数据完整性和健壮性。。虽然不做关系的限制,在程序里可以控制,但是谁能保证一定不出错呢?所以强制关系,对于新手是最适合不过的,新手不要怕麻烦,程序不出错才是最重要的,如果不建关系而导致数据库里有不正确的数据,那么测试找错就更麻烦了
      

  5.   


    数据库设计我们是采用 PowerDesigner 设计的,画好图后选择不同的数据库,可以导出 SQL 语句,
    用这些 SQL 来生成表。如果数据结构变化时得先更改数据库设计,再导出 SQL。这样的好处在于可
    以保证正式上线时的数据表结构与测试服务器上数据表结构完全一致。同意 pizzame 的观点,我们做的应用所有的表都是不建任何外键引用关系的,实体类中也没有关系,
    极少数情况下是为了方便才建有少量的关系,但在物理表中还是没有任何关系)特别是在使用 ORM 工具的情况下,在实体类中映射所有的关系,这样会造成效率很低,而且各种各
    样的关系维护起来有时候会非常非常麻烦。表之间的引用建议不建,但是表中的主键,还有诸如唯一键索引的这些必须建,因为这是数据安全的
    最后一道防线。
      

  6.   

    大的项目,因为业务比较复杂的,一般情况下是不在数据库上建立关系的,都是用事务和程序来控制的,因为业务可能会发生变化,一旦变化了,数据库关系上将很有可能发生变化,这样将花费很大的成本.而且一旦关系确立了,势必将增加数据库的压力.小项目来说,开发上会很轻松,有不少好处,但大点的项目,将不利于快速检索数据,更不利于用来做搜索引擎.但一般的permission ,person等还是很好.
      

  7.   

    我建外键主要是为了HIBERNATE在查询的时候方便但是我只留了外键,并没有留关系。