对象关系阻抗

各位好，大学毕业快一年了，在一家外企外包公司工作。大学里就对JAVA/.NET有兴趣，在公司进行了4,5个月的J2EE方面的培训，培训完正要做项目的时候，公司把我分到了ERP的部门，做Oracle EBS二次开发方面的，虽然对J2EE兴趣比较浓，但也不排斥Oracle erp方面的，所以就顺

喵。猫咪一直是敏捷开发拥护者。自己做项目总是先出设计实体然后映射成数据库表（猫咪是ORM框架拥护者）。最近进入一个项目，ER图已经画出来了。其中很多数据表上都有保留字段。我想问一下，在数据库设计中这么做到底是好还是不好？因为我觉得如果这些备用字段日后要使用的话，至少要改名字（总不能实际数据字段叫备用

有个客户关系管理系统。现在有几个业务对象，如投诉信息对象、报装信息、报修信息等等。每个业务里可以有要求回访，并且一个业务可能对应要求几次回访。所以把回访信息单独进行一个对象维护。 class CallBackInfo(){

Db4O数据库之运用(原创) 文/junglesong 注:欢迎与我讨论(junglesong@gmail.com) Db4O全名DataBase For Object

1，ECC的class由一个数据工厂生产是不是更好？2，engine既然是对class（数据）的操作，这些操作有大多数类似，有没有必要写一个公共父类让他们继承更好？3，Collection-class我觉得它的功能写在engine里不是更简单吗？4，由于这些东西大体相似，有没

有订单、发票、货物这样几个类 订单和发票都有自己的属性，但也有共同的属性：就是订单中的货物信息。 例如：订单：X年X月X日向XX公司订货：A货物 10件 200元B货物 2

有个客户关系管理系统。现在有几个业务对象，如投诉信息对象、报装信息、报修信息等等。每个业务里可以有要求回访，并且一个业务可能对应要求几次回访。所以把回访信息单独进行一个对象维护。 class CallBackInfo(){ id

banq您好！我非常同意您在数据持久层上面的见解，我也想过这样的问题：软件系统的分析与设计为什么要从数据库设计开始。或许是关系型数据库的本质特征所决定的，它着重于数据的持久化以及数据与数据间的关系，但其还没有达到值对象的层面。我想请问您的是，如何理解数据库中的关系理论？数据库

今天一早就看到CSDN很多关于存储过程和分层的讨论。其实现在我也遇到一个这样的问题。。公司要重新开发一套系统。。首先项目经理确定的是就是要保证在.jsp代码中不要有最好不要有任何JAVA代码。然后想把大多数的数据操作放在存储过程里实现。当时开会讨论的时候。我是建议MVC采用JSF结构

在坛子里转来转去，有些想法，按照以前重视数据库设计的时候，比如一个企业网站中的产品供求部分，我可能要写在一个表里面，设计一个字段加以区分，现在我可能会把这两个表分开，以遵循数据库设计服从程序逻辑的原则。 不知道我这样做对不对。感觉系统一下子多出很多表来，但

在关系数据库中如何把一对多,一对一,多对多转化为对象反正就是搞不懂了?

你一直提倡设计时，应该脱离数据库，但我遇到这类问题，还是觉得直接用 select 语句方便的多，板桥大哥能不能详细的指导一下，这类问题应该用什么方法，哪种更好？

很久之前就来过J道，但是没有怎么仔细关注，最近看的很多，感觉这里不错，道，是由中国特色的一个词，做软件系统就是从简单的代码工人，上升到一个道的境界，也就是系统分析设计啦等等，上升到一种思想。感觉这里高人牛人很多，希望大家继续努力，维护这一片净土，当前国内气氛太浮躁急功近利了，甚至还有人在争论是jav

有时建模又称数据建模，所以必然建模与数据是有一定关系的。所以说对业务领域建模避免不了会用到数据。用到数据时怎样避免联想到数据库那？想着业务模型实体，连带着就会想怎么控制它（这是逻辑）还会想到把模型对象怎么持久化，这样就会牵连我们的思维进入数据库的怪圈。而老板主张的似乎是存对业务领域抽象模型根本不考虑

要求如下：1、有四个实体 班级，学生，教师，课程2、关系如下 一个班级有多个学生 一个班级有多门课程，同一门课程可以有多个班级在上 一个教师可以教多门课程，一门课程可以有多个老师在上问题是：我应该如何建表呢？请各位指点

先设计好数据表,然后再映射成对象和先设计好对象再映射成数据表这两者有区别吗?