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

Posted 2023-03-12

【中文标题】如何说服某人规范化数据库？

【英文标题】：How to convince someone to normalize a database?

【发布时间】：2010-10-30 14:34:08

【问题描述】：

所以我一直在从事这个项目，我正在编写一个与我无法控制的数据库交互的 php 网站。该数据库是由一位在公司工作多年的同事“设计”的；所以最终决定留给他们决定。

当我第一次参与这个项目时，我去找同事并解释说数据库架构似乎有缺陷。我解释了规范化数据库以确保数据完整性问题、节省磁盘空间以及使程序员（我）的工作更轻松的重要性。我什至给出了当前设计中如何发生插入、删除和更新异常的示例。尽管如此，同事还是向我解释说，他们不想让项目的数据库过于复杂，而且它不会改变周期。

所以现在我已经进入该项目几个月了，每次我必须连接两个表以在彼此具有一对一关系的属性中插入一个值时，我都会感到头疼。 （所以该属性应该只是主关系的一个属性。）数据库看起来很糟糕，而且我担心几年后这会再次出现在我身上，因为我编写了使用数据库的前端。

关于如何说服“高级”同事正确设计数据库，有人有什么建议吗？或者关于如何避免在我没有任何参与的设计的道路上获得光顾多年的任何建议？我应该拒绝在未来从事这样的项目吗？在我的代码中留下评论说数据库不是我做的？

谢谢。

编辑：响应 cmets 的附加信息...

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

这里要填写一些细节，该数据库是为旅游请求系统设计的，因此其中的数据与访客信息、日期等有关。当前数据库使用的模式从头到尾都是不可预测的。从变量命名模式中最简单的不一致（例如：num_of_visitors、arrivalMethod 等）到为单个状态的一对一属性定义单独的关系。示例：statusID 表示游览请求的状态，它只能从一组可能的状态（已批准、拒绝、待定、取消）中选择一个有效状态。由于某种原因，数据库有一个状态表，其中包含：tour_id(Primary旅游关系的关键），状态ID。这允许为每个游览请求定义多个状态。根据设计，旅游请求在任何给定时间都应该只处于一种状态。所以这是设计上的缺陷，不是我的疏忽。

【问题讨论】：

没有建议，因为这是一个管理问题。不过，你确实有我的同情。

无论您的论点多么连贯和合乎逻辑，您是否认为管理层会支持您的同事？

如果她处于优越的位置，对你来说事情可能会很艰难。如果是我，我会开始发送一些简历！

她是技术人员还是公司里有其他人技术人员？

2 个月？那不好，你要重写多少代码？听起来 Db 换船已经启航了。

【参考方案1】：

换工作。

编辑：

简短的回答不是因为我在开玩笑或没有认真对待这个问题。 我以前也遇到过这样的情况。坏数据库不是问题。问题是盲目或无知的管理。我的意思是，如果他们不知道或不在乎重要的技术决策是由不称职的人做出的，那么情况会更糟。就像走进沼泽一样。

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

【讨论】：

是因为数据库规范化程度不高？老实说？

数据库是技术问题：不是。麻烦、责备和麻烦将糟糕的数据库设计的政治联系在一起：是的。但是，现在不是寻找新工作的时候......

如果公司有不懂基础的高级开发人员和不关心前景的管理层，那不是很好。也许不是换公司，而是换公司的职位。

gbn：总是该找份新工作了。告诉面试官你正在寻找新的绿色牧场。 ;)

我的工作恰好是周围最好的工作之一（在我看来）。这里的问题只是几个坏蛋。 （我认为几乎每个拥有 100,000 多名员工的雇主都是如此。）所以这不是一个真正的选择。也许我可以申请她的工作，你……嗯。

【参考方案2】：

根据我的经验，不幸的是，这些类型的情况通常以无法取胜的方式告终。您可以做一些事情来使自己远离设计：

在代码中实现数据访问层，尽可能多地抽象出实际的数据库设计。通过这种方式，您可以以更好的格式构建代码，并有效地“远离”自己使用和被指责为糟糕的数据库设计。 在数据库中创建视图以更符合逻辑的格式访问数据 如果有机会，可以对表/代码进行小的重构，如果可以的话

我不会在代码中加入贬义的 cmets，因为它很可能会再次困扰您。在您的数据访问层中，您可以放入客观/非冒犯性的 cmets，解释为什么要抽象出特定设计，以及如何以不同的方式设计它。

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

【讨论】：

好建议！数据访问层和信息丰富的 cmets 听起来是我的最佳选择。

【参考方案3】：

也许您可以指定您需要对该数据库执行的操作，并建议她将它们实现为数据库中的存储过程？ ...肯定会将问题放在它所属的地方...与导致它的人。

【讨论】：

这是个好主意。至少要将麻烦的不良设计问题交还给他们的创造者。我可以试一试，但想象一下它会被击落。

【参考方案4】：

最积极的方式是与同事合作，并尝试发展和教育他们的思维方式。也许讨论你过去犯过的错误会很容易打破僵局，并向他/她展示设计不佳的系统的影响。

如果您过去没有太多不好的经历可以帮助您，那么我建议您记录完成特定任务/缺陷需要多长时间（时间或金钱）。然后，您可以生成统计数据，所有经理都喜欢图表，该图表有望显示随着时间的推移添加功能或解决缺陷所需的时间长度如何增加。

希望这会有所帮助。

【参考方案5】：

这个问题可以改写为包括任何设计和实现，无论问题领域如何。

当你遇到这样的情况时，这是一个很大的挫败感。幸运的是，我没有多次参与这些，并且我能够在很大程度上避免受到影响的 SW 部分。或者构建一个中间层，让您使用更合理的数据库布局。

如果高级设计师和管理层不关心/不理解，通常也没什么可做的。任何时候需要对已经存在了一段时间的 sw 进行任何更改都是一样的。由于各种心理原因，首先要让设计系统的人批准更改通常是不可能的，除非您是上级并且可以“强制”解决问题。即使这样，在某些情况下它也可能不可行（您可能最终需要对您的软件进行太多更改）。

但是，如果您遇到性能等特定问题，则可能是一种可能性。如果您可以证明更好的数据库设计可以解决这些问题，您就可以取得一些进展。

【参考方案6】：

试图将设计不佳的数据库隐藏在层后面只是一种“黑客行为”，IMO 应该是 B 计划。对于 A 计划，我会尝试“升级”到更高级别。

正如您所描述的，您无权影响弄乱数据库的人。然后我会去找架构师（假设有），如果没有架构师，我会去找项目经理。

用有据可查的事实来支持你的论点非常重要，这些事实证明了糟糕的设计已经对你正在构建的系统产生了影响。其他事实可能是来自专业数据库社区的不良设计数据库的众所周知的问题。

我没有关于您的情况的足够信息，但是当我遇到坚持设计糟糕的技术解决方案的客户时，我通常会尝试这样做。

【参考方案7】：

通常情况下，开发人员需要与请求荒谬事物的客户合作，或者需要维护/使用设计非常糟糕的遗留代码。当然，您应该尝试说服/教育您的同事应该如何设计数据库，但您的主要工作应该是提供最优质的源代码。通常情况下，我们需要处理这种情况。

我会建议按照已经给出的建议在数据库周围创建一个层。用 cmets 填充它，例如“做这个复杂的事情，因为 db 表 1 和 2 没有标准化”。不要在你的cmets中提出批评。保持他们严格的技术。偶尔与您的同事/经理讨论数据库设计。买一本相关的书，放在某个地方让大家看。当有人要求时，提出借给它。不过，您的主要努力应该是编写好的代码。

【参考方案8】：

带他们去地下室。 让他们选择携带一张大沙发或四把小椅子:)

【参考方案9】：

当她说她不想使数据库过于复杂时，也许她的意思是她不知道或不擅长规范数据库。在这种情况下，一种方法是尝试让她相信规范化的好处，并让她学习数据库规范化。规范化的一个原因是仅仅创建一个数据库并不是数据库的唯一要求。数据库之所以存在，是因为它用作数据存储。什么存储数据？应用软件。因此，数据库创建者应该非常尊重软件开发人员，以使她对数据库进行规范化。否则，这将是一个非常尴尬的情况。为了让事情变得简单，您可以先展示一些更简单的规范化操作来开始使用它。

【参考方案10】：

您可能无法说服数据库设计人员重新设计数据库，特别是如果已经针对现在存在的数据库编写了大量代码。

但是，您确实需要扩大词汇量来描述设计良好的数据库和设计不佳的数据库之间的区别。有很多糟糕的数据库设计不能仅仅通过规范化来解决。您给出的一个示例令人费解，因为当一个好的设计将数据放在同一个表中时，您必须连接来自不同表的数据。

分解应该保持组合的表通常不是规范化失败。几乎所有规范化失败都会导致组合表应该被分解。从你的 cmets 关于指导她处理更新异常，我敢肯定你已经知道我可以教你关于正常形式的任何内容。

出于不良原因分解表（有时称为“超规范化”）是另一种设计缺陷。这个缺陷引起的编程问题与归一化不足引起的编程问题非常不同。

有多少其他程序员开发了在同一个数据库上工作的代码？其他程序员对设计有何看法？如果他们真的很开心，那会进一步降低你改变事物的机会。如果它们都弯曲变形，您可以通过在数量上找到力量来说服设计师。我知道，我知道，这就是政治，我敢打赌你讨厌政治。

当我过去教程序员有关数据库编程和设计的时候，学生们经常会问为什么在数据库工作中有这么多政治因素。我最终想出了一个简单的答案：

当数据库被广泛使用时，就会发生数据共享。这意味着知识共享。知识就是力量。当权力被分享时，政治就会发生。

【参考方案11】：

查找由非规范化引起的错误。如果数据库没有合适的约束（我猜在这种情况下不会），这样的错误将存在。我会把钱放在上面。如果您正在使用错误跟踪器，请查看那里。如果没有，请自行解决。无论哪种方式，您都可以证明此类错误会造成多大的损害，以及清理它们的成本。

【参考方案12】：

向高级管理人员展示这个问题。这将向他们表明，某种形式的规范化不仅仅是数据库的某种“复杂性”，而是绝大多数有能力的开发人员认为是基本的标准过程。