最近项目中遇到数据库设计上的问题,在此向高手请教

喵。猫咪一直是敏捷开发拥护者。自己做项目总是先出设计实体然后映射成数据库表(猫咪是ORM框架拥护者)。最近进入一个项目,ER图已经画出来了。其中很多数据表上都有保留字段。我想问一下,在数据库设计中这么做到底是好还是不好?因为我觉得如果这些备用字段日后要使用的话,至少要改名字(总不能实际数据字段叫备用字段吧),而且外键关联也要加上去。我觉得这么改,还不如到时候直接增加字段。都是要改表结构,我觉得留备用字段没什么用。而且如果留的太多,是否太浪费空间了?
上网搜了一下,有人说留下备用字段,可以避免编译全部程序?猫咪在这里不理解。如果不是程序逻辑需要修改,干嘛修改表结构?
还有,猫咪看到有人说数据库设计中出现“闭合环”不好。猫咪想问一下,什么是“闭合环”?是不是猫咪理解的数据表的一个字段的外键指向数据表自己的主键?反正猫咪知道这样的话,写某些SQL语句超级麻烦。不知自己理解得对不对。因为猫咪都是先设计实体,所以没遇见这种情况。项目已经决定使用Hibernate。请问这么一来是不是映射就麻烦了。
猫咪在数据库设计方面相对薄弱一些,希望在线的朋友们帮猫咪分析分析。

用hibernate就无法解决此类问题。

>猫咪是ORM框架拥护者 因为猫咪都是先设计实体

对不起,开个玩笑,好像你没有找到面向对象分析的重点,虽然你是ORM拥护者,可是你一直在谈数据库,放弃数据库设计的概念。数据库结构只是对象的输出结果,就象我们用word输入我们的文本,可是我们会关心这个文本是以什么字段格式保存的吗?同样,我们用Java实现输入我们的业务对象(类似文本),可是为什么我们要关心这个业务对象是以什么字段格式保存的呢?

使用Evans DDD和设计模式来研究你的实体对象,它是不是符合业务需要,是不是需要动态扩展,如何用对象的语言来动态扩展。

你不太懂数据库,那就对了,如果你懂数据库了,你再用OO,你会感到异常痛苦,打个比喻:你的母亲和老婆两个你都爱,但是他们两一旦有矛盾你就痛苦,因为你太看重两个,如果你只看重一个,就没有痛苦了;数据库和对象就象你的母亲和老婆,如果两个你都看重,怎么会在使用ORM时不痛苦呢?这种痛苦原因来自哪里?思维问题。


楼上的例子也太...

她们有矛盾,当然是自己挺身出来做适配器拉,呵呵.

每一边都要甜言密语,不过如果你更看重哪一方的话,你就得多下点功夫到那一方.

我只是个打工的。所以很多事情不是我能决定的。我现在只是试用期,设计还轮不到我。上面这么说了,就得这么做。我自己设计当然希望先抛开数据库,把对象设计出来。然后映射到数据库。我自己在开发一个试验的商城程序的时候,就是先设计中间的业务模型。结果持久层制作的时候感觉映射很容易。至于表上留备用字段,是客户的要求。我只是想问问大家,这么做到底好不好。

>我只是想问问大家,这么做到底好不好
如果好,你会来问问题吗?就是不好,你觉得痛苦,所以才来问问题,现在我告诉你问题的原因,可不能告诉你头痛医痛、脚痛医脚的办法。

对于你这种实际情况,唯一的选择:不要用Hibernate,必须放弃一头啊。

如果对Hibernate的设计方法不熟悉,就不要用了,到项目后期出现的问题会令你头痛的很啊!