所以我一直在从事这个项目,我正在编写一个与我无法控制的数据库交互的 php 网站。该数据库是由一位在公司工作多年的同事“设计”的;所以最终决定留给他们决定。
当我第一次参与这个项目时,我去找同事并解释说数据库模式似乎有缺陷。我解释了规范化数据库以确保数据完整性问题、节省磁盘空间以及使程序员(我)的工作更轻松的重要性。我什至给出了当前设计中如何发生插入、删除和更新异常的示例。尽管如此,这位同事向我解释说,他们不想让项目的数据库过于复杂,而且它不会改变周期。
因此,现在我已经进入该项目几个月了,每次我必须加入两个表以在彼此具有一对一关系的属性中插入一个值时,我都会把头发拉出来。(所以属性应该只是主关系的一个属性。)数据库看起来很糟糕,而且我担心几年后这会再次出现在我身上,因为我编写了使用数据库的前端。
有人对如何说服“高级”同事正确设计数据库有任何建议吗?或者关于如何避免在我没有任何参与的设计的道路上获得光顾多年的任何建议?我应该拒绝在未来从事这样的项目吗?在我的代码中留下评论说数据库不是我做的?
谢谢。
编辑:回应评论的附加信息......
我知道数据库的非规范化对于提高速度很有用,所以我不会忽视这一点。对于那些没有听说过这种策略的读者,我将举例说明。数据库设计者通常有一个地址关系,列出了用户的街道、城市、州和邮政编码。虽然每个人都知道邮政编码决定了城市和州,因此构成了一个将邮政编码索引到城市和州的表。通常,数据库设计人员会将这两个表组合在一起,并预见到对用户地址的每个查询都需要从地址表到 zip 表的连接,从而对它们进行非规范化。这最终加快了查询过程,并且是对数据库设计部分进行非规范化的合理推理。
在这里填写一些细节,该数据库是为旅游请求系统设计的,因此其中的数据与访客信息、日期等有关。当前数据库使用的模式从头到尾都是不可预测的。从变量命名模式中最简单的不一致(例如:num_of_visitors、arrivalMethod 等)到为单个状态的一对一属性定义单独的关系。示例:statusID 表示游览请求的状态,它只能从一组可能的状态(已批准、拒绝、待定、取消)中选择一个有效状态。由于某种原因,数据库有一个状态表,其中包含:tour_id(Primary旅游关系的关键),状态ID。这允许为每个游览请求定义多个状态。根据设计,旅游请求在任何给定时间都应该只处于一种状态。