对象关系阻抗

论坛里一直在讨论如何OO,如何建模,如何处理各种情景,那么,当我们面对旧系统,又有什么好办法处理这些问题? 当所有的类都是由关系数据库导出,不是使用组合而是添加了一个又一个字段进行关联.Hibernate成了另一种SQL语句,这种系

这些天看了一遍《领域驱动设计》，有个地方不太明白，书中非常强调随着对应用需求的深入理解以及为适应需求变化，需要不断重构领域模型，领域模型是不断在完善了，但数据持久化方面呢？或者更直接的说，数据库的结构方面呢，是需要随着领域模型的变动而随之变动，还是基本不动，只是变动O/M部分，这样一来，是不是会造成

要谈方法，这个世界其实只存在两种：一是将复杂问题简单化的方法；一个是将简单问题复杂化的方法。 你使用什么样的方法，你就有什么样的世界观，就是什么样的人，但是对于软件这个领域，你只能选择前者。

大多数程序员都被灌输这样一个观念:一个合格的程序员数学要好.在面向对象范式成为软件开发的主流的时代,需要学好数学吗? 我更认同编程是一种艺术,尤其是现在的DDD,提供了更大的发挥空间. 数学本质上是"抽象",我们的建模也是"抽象",但这两种抽象过程是截然不同的思维过程.个人观点

我在一本书上看到这样一句话：“对于简单的系统使用手工方式编写映射文件会比较简单，但对于大型系统，最好使用XDoclet或者其他工具来自动保证映射文件与域模型的一致性，这可以在很大程度上减少由于域模型的变化而带来的麻烦。” 我比较困惑，因为我一直是用手工写的“hbm”映射文件，而不用去管

　　在J道时间呆得久了，就越发得对公司现在的开发现状感到痛心和无奈。对自己得前途也不自觉得感到非常的担心。 　　我在一家专门从事电信行业开发的软件公司的工作。公司开发的项目主要采用得架构是前台用JAVA做开发，后台服务用pro C做开发，通过weblogi

项目需求分析如下:学生 ---选课 ---查看课程表 ---上课 ---查看考试表 ---考试 ---查成绩 ---评教 ---管理个人信息 教师 ---授课

为了提高查询效率,在许多地方不可避免的采用冗余字段,从而对一个对象的更新,不得不对所有其冗余字段的对象相应属性进行更新,而这样的逻辑是放在dao层面才完成还是放在bo层来做?说他是业务问题实在又说不过去,所以倾向于在dao来完成.对于这种情况 有什么设计上的建议?

我对这个话题很感兴趣,不知道有谁能够告诉大家,关系型数据库出现的背景以及它所解决的问题.

最近在看夏昕的《深入浅出Hibernate》，有若干问题，向前辈请教 （1）O/R Mapping 还是R/O Mapping，就是E-R建模还是对象建模的问题，毫无疑问，被持久化的应该是对象，数据库表只是一种手段。问题来了，既然我们选择了对象建模，那么按照传统的软件工程理论，数据库设

我最近看了banq对于数据库和领域建模的分析的文章。似乎有点想法。想提出自己的意见请大家看看自己的思路是否正确 比如说在一个多对多应用中 假设我们先从设计数据库表开始的话，比如有 用户 用户角色 和角色 三张表这个时候，我用HIBERNATE影射当前表应该生成是4个

以数据为中心的开发方法，我只知道由E-R建模分析问题，没听说过从数据表分析。如：信息工程(IE)和IDEF1x。关系模型的确有它的弱点，面向对象方法的确有独到之处。但不至于为了突现面向对象方法而歪曲并贬低其他方法。“数据表的关系主要是通过外健或专门关联表来表达的，这种关系虽然可以反映1:1或1:N这

如果数据库按面向对象的思路设计，怎么设计出一套能查询到历史操作记录，能统计历史，能退回操作的数据库

小弟初来乍到，先向各位前辈问好！现在我们组里的项目是借用sematic web的描述客观世界的表现规范（RDF,OWL，三元组等），然后对源数据进行一系列的推理。现在就是在苦恼用关系数据库还是对象数据库来存储这些三元组以及其详细的推理过程。其实之前已经想好了用关系数据库如何构造表来表示这些三

这两天看hibernate,ORM看的我头晕，什么1对多，多对1，多对多，很繁杂，远远没有HQL简便。ORM 和 HQL 是什么关系，只可以用HQL而不用ORM 吗？

drop procedure if exists prc_page_result;create procedure prc_page_result (in currpage int,in columns varchar(500),in table