归一化导致许多基本和理想的特征,包括审美愉悦.此外,它在理论上也是"正确的".在这种情况下,非规范化被用作折衷方案,用于实现性能的校正.除了性能之外,还有其他任何理由可以对数据库进行非规范化吗？
在为数据库(例如MySQL)设计模式时,会出现是否完全规范化表格的问题.
一方面连接(和外键约束等)非常慢,另一方面,您获得冗余数据和不一致的可能性.
这里的"优化最后"是正确的方法吗？即创建一个由书本标准化的数据库,然后查看可以非规范化的内容以实现最佳速度增益.
对于这种方法,我担心的是,我将采用可能不够快的数据库设计 - 但在那个阶段重构模式(同时支持现有数据)将非常痛苦.这就是为什么我很想暂时忘记我所学到的关于"正确"RDBMS实践的一切,并尝试一次"平台"方法.
这个数据库是否会插入重量会影响决定吗？
所以我一直致力于这个项目的工作,我正在编写一个与我无法控制的数据库交互的php网站.该数据库是由一位同事"设计"的,该员工已经在公司工作了很多年; 所以最终决定留待他们决定.
当我第一次被带到这个项目上时,我去了同事并解释说数据库模式似乎有缺陷.我解释了规范化数据库以确保数据完整性问题,节省磁盘空间以及它将使程序员(我)工作更容易的重要性.我甚至举例说明了当前设计中如何发生插入,删除和更新异常.然而,同事向我解释说,他们不想让项目数据库过于复杂,并且不会改变时期.
所以现在我已经进入项目的几个月了,每次我必须加入两个表来在一个彼此具有一对一关系的属性中插入一个值时,我就会把头发拉出来.(所以属性应该只是主要关系的一个属性.)数据库看起来很可怕,而且我害怕随着时间的推移,这将会回到我身上,因为我编写了使用数据库的前端.
有没有人有任何关于如何与"优秀"同事交谈以正确设计数据库的建议？或者任何有关如何避免光顾未来的设计的建议我没有参与任何设计？我是否应该在将来拒绝这样的项目？在我的代码中留下评论说数据库不是我在做什么？
谢谢.
编辑:回复评论的其他信息......
我知道数据库的非规范化对于速度目的是有用的,所以我不会忽略它.对于那些没有听说过这种策略的读者,我将举例说明.数据库设计者通常具有列出用户的街道,城市,州和邮政编码的地址关系.虽然每个人都知道邮政编码决定了城市和州,因此构成了一个将邮政编码索引到城市和州的表格.数据库设计人员通常会将这两个表组合在一起,对它们进行去规范化,使用户地址的每个查询都需要从地址表到zip表的连接.这最终加速了查询过程,并且是数据库设计部分非规范化的合理推理.
为了在这里填写一些细节,数据库是为巡回请求系统设计的,因此其中的数据与访问者信息,日期等有关.当前数据库使用的模式从开始到结束是不可预测的.从变量命名模式中最简单的不一致(例如:num_of_visitors,arrivalMethod等)到为单个状态一对一属性定义的单独关系.示例:statusID表示巡视请求的状态,它只能从一组可能的状态(已批准,已拒绝,待处理,已取消)中选择一个有效状态.由于某种原因,数据库的状态表包含:tour_id(主要)旅游关系的关键),statusID.这允许为每个巡回请求定义多个状态.根据设计,巡回请求应该在任何给定时间仅处于一种状态.所以这是设计中的一个缺陷而不是对我的疏忽.
我听说我的团队负责人说,在过去的一些项目中,他们不得不取消规范化,以提高查询速度.
我认为它可能与表联盟有关.
有更多的精益表真的没有脂肪表少吗？
从相对未规范化的形式获取数据库并对其进行规范化时,资源利用率会发生什么变化(如果有的话)？
例如,规范化通常意味着从更少的表创建更多的表,这意味着数据库现在具有更多的表,但是其中许多表非常小,允许经常使用的表更好地适应内存.
更多的表还意味着需要(可能)更多的连接来获取抽象出来的数据,因此可以预期系统需要进行的更多连接会产生某种影响.
那么,规范化非规范化数据库对资源使用有什么影响(即什么会改变)呢？
编辑:为了添加一些上下文,我有一个现有的(即遗留的)数据库,有超过300个可怕的表.大约1/2的数据是TEXT,另一半是char字段或整数.没有任何限制.我问的原因主要是获取更多信息,以说服其他人事情需要改变,并且不会降低性能或可维护性.不幸的是,那些我必须说服的人已经足够了解非规范化数据库的性能优势,希望尽可能避免规范化.