如何说服某人标准化数据库？

Question

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

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

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

对于如何说服“高级”同事正确设计数据库，有人有任何建议吗？ 或者有什么建议可以帮助我避免多年来因我没有参与过的设计而受到光顾吗？ 我以后是否应该拒绝从事这样的项目？ 在我的代码中留下评论说数据库不是我做的？

谢谢。

编辑：响应评论的附加信息...

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

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

Answer 1

不幸的是，根据我的经验，这些类型的情况往往最终会成为一场无法获胜的战斗。 您可以采取一些措施来远离设计：

• 在代码中实现一个数据访问层，尽可能多地抽象出实际的数据库设计。 通过这种方式，您可以以更好的格式构建代码，并有效地“远离”自己，避免使用糟糕的数据库设计，并避免因糟糕的数据库设计而受到指责。
• 在数据库中创建视图，以更符合逻辑的格式访问数据
• 有机会时对表/代码进行小型重构，如果你能逃脱惩罚，

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

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

Answer 2

换工作。

编辑：

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

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

Answer 3

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

但是，您确实需要扩展词汇量来描述设计良好的数据库和设计不良的数据库之间的差异。 有很多糟糕的数据库设计不能仅仅通过规范化来修复。 您给出的一个例子是令人抓狂的，因为当一个好的设计将数据放在同一个表中时，您必须连接来自不同表的数据。

分解本应保持组合状态的表通常并不是规范化失败。 几乎所有规范化失败都会导致本应分解的组合表。 从您关于指导她更新异常的评论中，我很确定您已经知道我可以教您有关正常形式的任何内容。

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

有多少其他程序员开发在同一数据库上运行的代码？ 其他程序员对这个设计感觉如何？ 如果他们真的很高兴，那就进一步减少了你改变事情的机会。 如果它们都变形了，你也许可以通过数量的力量来说服设计师。 我知道，我知道，这就是政治，我敢打赌你讨厌政治。

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

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

Answer 4

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

Answer 5

也许您可以指定需要对此数据库执行的操作，并建议她将它们实现为数据库中的存储过程？ ...肯定会将问题归咎于引起问题的人。

Answer 6

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

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

希望这可以帮助。

Answer 7

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

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

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

我没有足够的关于您的情况的信息，但这就是我在遇到坚持采用设计不良的技术解决方案的客户时通常会尝试做的事情。

Answer 8

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

我建议遵循已经给出的建议，在数据库周围创建一个层。 用注释填充它，例如“做这个复杂的事情，因为数据库表 1 和 2 没有标准化”。 不要在评论中提出批评。 让它们严格保持技术性。 偶尔与您的同事/经理讨论数据库设计。 购买一本相关的书并将其放在某个地方供每个人查看。 当有人询问时，主动提出借给他。 尽管如此，你的主要努力应该是编写好的代码。

Answer 9

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

Answer 10

当她说她不想使数据库过于复杂时，也许她的意思是她不知道或没有能力规范化数据库。 在这种情况下，一种方法是尝试让她相信规范化的好处，并送她去学习数据库规范化。 规范化的一个原因是创建数据库并不是数据库的唯一要求。 数据库之所以存在，是因为它是用来存储数据的。 什么存储数据？ 应用软件。 因此，数据库创建者应该非常尊重软件开发人员，以便她对数据库进行规范化。 不然的话，场面就真的很尴尬了。 为了简化问题，您可以首先展示一些更简单的规范化操作来开始使用。

Answer 11

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

Answer 12

这个问题可以重新表述为包括任何设计和实现，无论问题领域如何。

当你遇到这样的情况时，这是令人沮丧的一个重要原因。 幸运的是，我没有多次涉及到这些问题，并且我能够在很大程度上避免受到影响的软件部分。 或者构建一个中间层，允许您使用更合理的数据库布局。

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

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