如何说服某人正常化数据库？ [英] How to convince someone to normalize a database?

问题描述

所以我一直在这个项目的工作，我在编码一个php网站，与一个数据库交互，我无法控制。数据库是由一个同事与我公司多年的时间设计的;所以最终决定由他们决定。

当我第一次参加这个项目时，我去了同事，并解释说数据库模式似乎有缺陷。我解释了标准化数据库以确保数据完整性问题，磁盘空间节省的重要性，并且它将使程序员（我）的工作更容易。我甚至给出了在当前设计中可能发生插入，删除和更新异常的示例。然而，同事向我解释说，他们不想使项目的数据库过于复杂，并且不会改变期限。

现在我是一对夫妇几个月进入项目，每次我必须连接两个表，以在一个属性中插入一个值，彼此具有一对一的关系，我拉我的头发。 （所以属性应该只是主关系的一个属性。）数据库看起来很可怕，我恐怕自从我编程使用数据库的前端，这将回到我。 p>

有没有人有关于如何谈论上级同事正确设计数据库的任何建议？或任何建议，如何避免得到光顾岁月的设计我没有任何部分的道路？我应该只是拒绝在未来的项目这样的工作？在我的代码中发表评论，说数据库不是我的？

感谢。

编辑：回应评论的其他资讯...

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

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

解决方案

根据我的经验，这些类型的情况通常最终会导致不可战胜的战斗，不幸的是。您可以做些什么来使自己与设计保持距离：

• 在抽象出的代码中实现数据访问层大多数实际的数据库设计尽可能。这样，您可以以更好的格式构建代码，并且有效地使自己避免使用和被指责为错误的数据库设计。


• 在DB中创建视图以访问数据更合乎逻辑的格式


• 在有机会的情况下对表/代码进行小型重构，如果可以解决它

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

事情真的很糟糕，没有人会支持你，可能是找一份工作的时候了。

So I’ve been working on this project at work where I’m coding a php website that interacts with a database I have no control over. The database was "designed" by a co-worker that has been with the company many more years then I have; so in the end decisions are left for them to decide.

When I was first pulled aboard on this project I went to co-worker and explained that the database schema seemed flawed. I explained the importance of normalizing the database to insure data integrity issues, disk space savings, and that it would make the programmer’s (me) job easier. I even gave examples of how insertion, deletion, and update anomalies could occur in the current design. Nevertheless the co-worker explained to me that they did not want to over complicate the project’s database, and that it would not change period.

So now I’m a couple months into the project and I’m pulling my hair out each time I have to join two tables to insert a value in an attribute that has a one to one relation with each other. (So the attribute should have just been an attribute of the main relation.) The database looks horrible, and I’m afraid that years down the road this will come back on me since I programmed the front end that uses the database.

Does anyone have any suggestions as to how to talk a "superior" co-worker into correctly designing a database? Or any suggestions on how to avoid getting patronized years down the road for a design I didn’t have any part of? Should I just refuse to work on projects like this in the future? Leave a comment in my code saying the database wasn’t my doing?

Thanks.

Edit: Additional information in response to comments...

I know that the de-normalization of a database can be useful for speed purposes, so I’m not overlooking this. For those reading who haven’t heard of this tactic I’ll illustrate an example. Often database designers have an address relation that lists a user’s street, city, state and zip code. While everyone knows that a zip code determines the city and state, therefore constituting a table indexing zip codes to city and states. Often database designers will combine the two tables, de-normalizing them with foresight that every query for a user’s address would require a join from the address table to the zip table. This ultimately speeds up the querying process, and is sound reasoning for de-normalization of portions of a database design.

To fill in some details here the database is designed for a Tour Request system, so the data within is related to visitor information, dates, etc. The schema that the current database uses is unpredictable from start to finish. From the simplest inconsistencies in variable naming patterns (example: num_of_visitors, arrivalMethod, etc) to having separate relations defined for a single state one-to-one attribute. Example: statusID represents the status of the tour request, it can only ever have one valid state selected from a group of possible states (Approved, denied, pending, canceled.) For some reason the database has a status table containing: tour_id(Primary key of tour relation), statusID. This allows for multiple states to be defined for each tour request. Which, by design a tour request should only be in one state at any given time. So it’s a flaw in the design not an oversight of mine.

解决方案

From my experience, these types of situations often end up being un-winnable battles, unfortunately. A few things you can do to distance yourself from the design might be:

• Implement a data-access layer in the code that abstracts away as much of the actual database design as possible. This way, you can structure your code in a better format, and effectively "distance" yourself from using and being blamed for the bad database design.
• Create views in the DB to access data in a more logical format
• Make small refactorings to tables/code when you get a chance, if you can get away with it

I wouldn't put derogatory comments in the code, because it will most likely come back to haunt you. In your data access layer, you could put in objective/non-offensive comments explaining why you are abstracting away a particular design, and how it could be designed differently.

If things are really bad, and nobody else will support you, it might be time to look for another job.

这篇关于如何说服某人正常化数据库？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！