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

Question

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

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

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

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

感谢。

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

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

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

Answer 1

根据我的经验，不幸的是，这些类型的情况往往最终成为不可赢的战斗。您可以做的一些事情可以与设计保持距离：

• 在代码中实现数据访问层，尽可能多地抽象出实际的数据库设计。通过这种方式，您可以以更好的格式构建代码，并有效地“远离”自己使用并将其归咎于糟糕的数据库设计。
• 在数据库中创建视图以更合理的格式访问数据
• 如果你有机会，可以对表格/代码进行小的重构，如果你可以侥幸成功的话

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

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

Answer 2

改变工作。

编辑：

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

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

Answer 3

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

但是，您需要扩展词汇表来描述精心设计的数据库与设计不佳的数据库之间的差异。有很多不好的数据库设计只能通过规范化来解决。你给出的一个例子是撕掉你的头发，因为当一个好的设计将数据放在同一个表中时你必须连接来自不同表的数据。

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

由于不好的原因而分解表，有时称为“超常规”，这是一种不同的设计缺陷。由这个缺陷引起的编程问题与由于欠正常化引起的编程问题非常不同。

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

当我以前教过程序员关于数据库编程和设计的时候，学生们常常会问为什么数据库工作中有如此多的政治因素。我最终想出了简单的回答：

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

Answer 4

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

Answer 5

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

Answer 6

最积极的方式是与同事合作，努力发展和教育他们的思维方式。也许讨论你过去犯过的错误将是一个容易破冰的事，并向他/她展示设计不良的系统的含义。

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

希望这有帮助。

Answer 7

试图在设计层隐藏设计不良的数据库只是一个“黑客”而IMO它应该是计划B.对于计划A，我会尝试“升级”到更高级别。

如您所述，您无权影响弄乱数据库的人。然后我会去建筑师（假设有一个）或项目经理，如果没有建筑师。

非常重要的是要充分记录有关坏设计已经对您正在构建的系统产生的影响的事实。对于来自专业数据库社区的设计糟糕的数据库，其他事实可能是众所周知的问题。

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

Answer 8

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

我建议按照已经给出的建议在数据库周围创建一个图层。用“做这个复杂的事情，因为db表1和2没有规范化”这样的注释填写它。不要在你的评论中加以批评。严格保持技术性。偶尔与您的同事/经理讨论数据库设计。买一本相关的书并把它放在某个地方供大家看。当有人要求时，请提供贷款。不过，你的主要努力应该是编写好的代码。

Answer 9

带他们去地下室。 在携带大沙发或4把小椅子之间给他们一个选择：）

Answer 10

当她说她不想让数据库复杂化时，也许她的意思是她不知道或不能正常化数据库。在这种情况下，一种方法是试图说服她正常化的好处加上让她去研究数据库正常化。规范化的一个原因是仅创建数据库不是数据库的唯一要求。数据库存在是因为它用作数据存储。什么存储数据？应用软件。因此，数据库创建者应该非常尊重软件开发人员，以便对数据库进行规范化。否则这将是一个非常尴尬的局面。为了简化问题，您可以首先展示一些更简单的规范化操作，然后开始使用它。

Answer 11

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

Answer 12

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

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

如果高级设计师和管理层不关心/理解，通常没有太多事情要做。无论何时需要对sw进行一段时间的改变，它都是一样的。由于各种心理原因，除非你是上级并且能够“强迫”解决这个问题，否则通常不可能出于各种心理原因而获得设计系统的人批准的更改。即使这样，在某些情况下也可能不可行（你可能最终需要对你的sw进行太多改动）。

但是，如果您遇到性能等具体问题，可能会有一种可能性。如果您能够证明更好的数据库设计可以解决这些问题，那么您可以取得一些进展。