如何说服某人规范化数据库？

Question

所以我一直致力于这个项目的工作,我正在编写一个与我无法控制的数据库交互的php网站.该数据库是由一位同事"设计"的,该员工已经在公司工作了很多年; 所以最终决定留待他们决定.

当我第一次被带到这个项目上时,我去了同事并解释说数据库模式似乎有缺陷.我解释了规范化数据库以确保数据完整性问题,节省磁盘空间以及它将使程序员(我)工作更容易的重要性.我甚至举例说明了当前设计中如何发生插入,删除和更新异常.然而,同事向我解释说,他们不想让项目数据库过于复杂,并且不会改变时期.

所以现在我已经进入项目的几个月了,每次我必须加入两个表来在一个彼此具有一对一关系的属性中插入一个值时,我就会把头发拉出来.(所以属性应该只是主要关系的一个属性.)数据库看起来很可怕,而且我害怕随着时间的推移,这将会回到我身上,因为我编写了使用数据库的前端.

有没有人有任何关于如何与"优秀"同事交谈以正确设计数据库的建议？或者任何有关如何避免光顾未来的设计的建议我没有参与任何设计？我是否应该在将来拒绝这样的项目？在我的代码中留下评论说数据库不是我在做什么？

谢谢.

编辑:回复评论的其他信息......

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

为了在这里填写一些细节,数据库是为巡回请求系统设计的,因此其中的数据与访问者信息,日期等有关.当前数据库使用的模式从开始到结束是不可预测的.从变量命名模式中最简单的不一致(例如:num_of_visitors,arrivalMethod等)到为单个状态一对一属性定义的单独关系.示例:statusID表示巡视请求的状态,它只能从一组可能的状态(已批准,已拒绝,待处理,已取消)中选择一个有效状态.由于某种原因,数据库的状态表包含:tour_id(主要)旅游关系的关键),statusID.这允许为每个巡回请求定义多个状态.根据设计,巡回请求应该在任何给定时间仅处于一种状态.所以这是设计中的一个缺陷而不是对我的疏忽.

Answer 1

根据我的经验,不幸的是,这些类型的情况往往最终成为不可赢的战斗.您可以采取一些措施来使自己与设计保持距离,这可能是:

• 在代码中实现数据访问层,尽可能多地抽象出实际的数据库设计.通过这种方式,您可以以更好的格式构建代码,并有效地"远离"自己使用并被指责为错误的数据库设计.
• 在数据库中创建视图以更逻辑的格式访问数据
• 如果你有机会,可以对表/代码进行小的重构

我不会在代码中加上贬义,因为它很可能会回来困扰你.在您的数据访问层中,您可以提出客观/非攻击性的评论,解释您为什么要抽象出特定的设计,以及如何以不同的方式设计它.

如果事情真的很糟糕,没有其他人会支持你,那么可能是时候寻找另一份工作了.

Answer 2

换工作.

编辑:

简短的回答不是因为我在开玩笑或不认真对待这个问题.我以前一直处于这种状况.坏数据库不是问题.问题是盲目或无知的管理.我的意思是,如果他们不知道或不关心那些重要的技术决策是由不称职的人做出的,那么情况会更糟.这就像走进沼泽地.

认真考虑寻找新工作.对于开发人员来说,确实有很棒的工作场所.这个不是.你在浪费你的时间.