当我第一次在这个项目上登上时,我去了同事,并解释说数据库模式似乎有缺陷.我解释了数据库归一化的重要性,以确保数据完整性问题,节省磁盘空间,并使程序员(我)的工作更轻松.我甚至给出了在当前设计中如何插入,删除和更新异常可能发生的例子.然而,同事向我解释说,他们不想使项目的数据库复杂化,而且不会改变时期.

所以现在我几个月进入这个项目,每次我必须加入两个表,把一个值与一个一个一个的关系插入,我拉出头发. (所以这个属性应该是主要关系的属性.)数据库看起来很可怕,我恐怕这几年将会回到我身上,因为我编写了使用数据库的前端.

有没有人有任何建议如何说“优秀”的同事正确设计数据库？还是关于如何避免光顾年轻的设计的任何建议,我没有任何部分？我今天应该拒绝这样的项目吗？在我的代码中发表评论说数据库不是我的做法？

谢谢.

编辑：响应评论的其他信息…

我知道数据库的去规范化可以用于速度目的,所以我不能忽略这个.对于那些没有听过这个策略的读者,我将举一个例子.通常,数据库设计者具有列出用户街道,城市,州和邮政编码的地址关系.虽然每个人都知道一个邮政编码决定了城市和州,因此构成一个索引邮政编码到城市和州的表.通常,数据库设计人员将组合这两个表,将它们以规范化方式进行归一化,每个用户地址的查询都需要从地址表到zip表的连接.这最终加快了查询过程,并且是对数据库设计的部分进行去规范化的合理推理.

为了在这里填写一些细节,数据库是为旅游请求系统而设计的,因此数据与访问者信息,日期等相关.当前数据库使用的模式从头到尾都是不可预测的.从变量命名模式(例如：num_of_visitors,arrivalMethod等)的最简单的不一致到为单个状态一对一属性定义了单独的关系.示例：statusID表示巡视请求的状态,它只能从一组可能的状态中选择一个有效状态(已批准,被拒绝,挂起,取消).由于某些原因,数据库具有状态表,其中包含：旅游关系的关键),statusID.这允许为每个旅游请求定义多个状态.其中,通过设计,旅游请求在任何给定时间只应处于一个状态.所以这是设计的缺点,而不是我的监督.