16

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

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

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

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

谢谢。

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

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

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

4

12 回答 12

22

根据我的经验，不幸的是，这些类型的情况往往最终成为无法取胜的战斗。您可以做一些事情来使自己远离设计：

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

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

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

于 2009-06-02T06:51:40.817 回答
19

换工作。

编辑：

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

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

于 2009-06-02T06:48:05.520 回答
4

您可能无法说服数据库设计人员重新设计数据库，尤其是当已经有大量代码针对现在存在的数据库编写时。

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

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

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

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

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

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

于 2009-06-02T09:59:02.983 回答
3

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

于 2009-06-02T18:07:18.630 回答
2

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

于 2009-06-02T06:52:40.237 回答
2

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

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

希望这可以帮助。

于 2009-06-02T06:54:49.720 回答
2

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

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

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

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

于 2009-06-02T07:09:58.300 回答
2

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

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

于 2009-06-02T07:11:57.360 回答
1

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

于 2009-06-02T07:15:33.547 回答
1

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

于 2009-06-02T07:16:12.577 回答
1

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

于 2009-07-09T15:00:16.333 回答
0

这个问题可以改写为包括任何设计和实现，而不管问题域如何。

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

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

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

于 2009-06-02T07:02:32.137 回答