日期:2014-05-18 浏览次数:20661 次
<!-- Hibernate的附属属性设置 --> <property name="hibernateProperties"> <props> <prop key="hibernate.dialect">${hibernate.dialect}</prop> <!-- 数据库方言 --> <prop key="hibernate.show_sql">${hibernate.show_sql}</prop> <!-- 是否打印执行的SQL语句 --> <prop key="hibernate.hbm2ddl.auto">update</prop> <!-- [color=#FF0000]根据POJO类更新数据库[/color] --> <prop key="jdbc.fetch_size">50</prop> <prop key="jdbc.batch_size">25</prop> <prop key="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</prop> <prop key="hibernate.cache.use_query_cache">true</prop> <prop key="hibernate.connection.release_mode">after_transaction</prop> <prop key="hibernate.query.factory_class">org.hibernate.hql.ast.ASTQueryTranslatorFactory</prop> <prop key="transaction.factory_class">org.hibernate.transaction.JDBCTransactionFactory</prop> </props> </property>
------解决方案--------------------
一旦 调整了 数据库 那么不是 对 实体类 进行了修改吗?
必然修改。
除非你采用可能叫罗文(名字忘记了)的一种设计方案。
field_0
field_1
field_2
field_3
field_4
...一次性整150列,在扩展也就那样了!表不改。
DEF
必须有一个衍生字典。说白了就是对表的备注。也起到TRM的作用。这个设计很难的哦!
然后你以集合的形式操作表。
------解决方案--------------------
个人认为,如果持久层确定选用orm的话,那么在设计数据库表结构的时候就要从对象之间的关联关系去考虑的多一些。如果不选用orm,那么在设计表结构的时候会更多的从业务实体之间的关联关系和表结构的设计层面去考虑多一些。注意以上两种我都用了“多一些”,实际设计的时候还是要根据实际业务情况而定。
------解决方案--------------------
我不知道你们那些理论,我只知道数据库设计尽量不要冗余,尽量效率高,性能好,同时还要考虑扩展,不能改一下数据库就影响到以前的数据。实际项目中客户有太多数据是不能再动的,所以扩展性得考虑的比较周全。怎么设计我也不是很懂...看高手们讲吧,学习了~
------解决方案--------------------
我觉得数据库设计合理,冗余少,业务层与数据层分离,就应该基本达到扩展性良好的数据库设计要求了吧?
可以使用Hibernate将数据访问层分离出来,如果需要业务层与数据层进一步松耦合,还可以定义层间接口。
------解决方案--------------------
我现在的项目因为数据库没有设计好,现在是哭笑不得了,数据库设计论项目成败
------解决方案--------------------
总的来说数据表合理的设计是程序的最基本阿
数据表设计好了。。程序设计起来也会灵活和方便许多。。
具体还是要根据自己的需求去看更偏重于哪一方面吧。
------解决方案--------------------
数据库表从作用上来讲大致可分为三类:主表,从表,关系表,信息表
如果从作用上来考虑建表,可以有效的避免冗余,也有良好的可扩展性。
------解决方案--------------------
上面是myJavaRoad朋友最近发的技术帖,得到大家的积极参与,希望能够对来论坛的朋友带来帮助
鼓励大家可以定期把自己的知识梳理起来,
把自己知识或者疑惑都可以共享一下
以后要是可能的话,可以在我们Java版块搞个“个人系列”之类的,关键的是能对大家有帮助,就欣慰了!
------解决方案--------------------
------解决方案--------------------