这是公司正接的一个小项目的一部分业务。要求是记录预约人请求在某个时间和某个会见人会见的预约。因为这个申请是面向网络，而且没有任何权限用户验证，谁都可以提交申请。所以每次都要记录新的预约人、会见人和预约时间等信息。也就是说三者是一对一的关系。如果维持一对多的关系，预约人和会见人信息有可能被随意提交的申请破坏。
现在问题来了，我认为这是3个对象，但是我同事认为是只一张表。他的理由是因为是一对一的关系，所以放到一张表里又方便又快。
我无论是从面向对象的方面还是从数据库的方面看，都是3个，但他就是认定，一对一关系就可以放一张表，没有任何必要分成3个对象（对他来说是3个表）。上个星期差点吵起来。我们谁也说服不了谁，我们互相认为对方根本不懂数据库范式。我一说面向对象，他就说这就是一个预约对象，就是一张表。
大家来评论评论，难道是我学歪了？不是的话该如何反驳？反正现在是都放一个表里头了，没着，他权利比我大。
[该贴被admin于2009-04-07 15:47修改过]
实际
[该贴被netwr于2009-04-07 15:12修改过]
这有得争吗？
你们两争的不是同一个问题，打个比喻：你拿了三样东西在手里，你同事说可以放在他的一个盒子里，你叫嚷：我拿的是三个啊，你同事争论：可以放在一个盒子里啊。
对象是自由的，缺省生活在内存中，当然经常会从内存中放到磁盘的数据库上，内存和数据库硬盘只是对象的活动空间不一样，这些都不会影响对象设计本身。
不是一个对象一定对应一张表
那么问题可以这么比喻。比如是一个盒子。有三类积木。然后我是把这3类积木分别用3个小盒子装起来放进去还是直接倒进去？
我认为是应该分类摆放，他认为放进去就可以了。
我想不通你们是如何交流的，按你同事思维来看的话，何来对象之说？根本就没对象！
还是妥协点吧，跟同事利用事务脚本模式合作吧，对象与关系必须得有一方妥协，您的同事可是您的上司。
面对对象跟几张表有关么？？这个问题很简单，如果是就是1：1:1的关系无论那种设计都是没有问题的，不过如果将来业务模式进行了修改，可以1：N，可能你的方案修改的程度是最小的。
设计好对象与对象之间的关系，交由orm框架去处理几张表的事情吧
其实现在就是领域模型中预约本身和两个参与人到底是完全一体，还是应该分成3个子部分。
不过因为他都是数据库思维（我觉得他数据库思维也不合格，不过估计他也是这么看我的）。所以我们的争论更像3个表和1个表的争论。
其实我认为预约人和会见人都应该派生于人这个对象，ORM映射的话应该出3个表，加上预约本身4个表了。
你们两个谈的不是一个话题，你在谈需求分析，他直接干上了，就象谈朋友，你们还在接触摸索阶段，他已经抱着亲嘴了。
我给你用四色图画一下需求，先看一下需求的真实模型，然后再细化，使用DDD细化到可以和他数据库接壤，使用DDD就相当于你们谈朋友开始牵手了，从接触 到牵手 再到亲嘴，要有一个过程，对待软件开发更应该这样。
这么说是我的想法比较靠谱了！
那家伙真是没法说了。昨天让我把预约记录上的性别、记录状态从枚举改成静态常量。我问他为什么不要枚举，用这个定义在JPA里很方便的处理像性别这样的固定范围的属性。结果他告诉我说写成枚举，如果要修改的话，需要改代码。但是没过5分钟就要我把删掉的枚举的内容作为静态常量放到预约记录类里头去。这他就不怕修改代码了？反正我是不掺和他们这块的开发了，没得给自己找气受。
枚举就是为了代替static final而产生的
和他真人PK，最后站着的说了算
那我就先拍辞职报告吧。最近奶奶老妈相继住院，在没有下家的情况下不能随便辞职。
