设计数据库：你不会想要做的7件事

您的数据库设计很糟糕。

没有人告诉你这个原因的原因有两个：无知或冷漠。他们要么不知道它是坏的，要么他们不在乎。

嗯我关心糟糕的设计，因为我通常承担必须快速运行查询并克服糟糕设计的限制的负担。作为过去15年的数据专家，我已经看到（并建立了）我的数据库设计份额。有些是好的，有些是好的，但大多数让我想要用纸夹shiv刺伤某人。

当我遇到一个次优的设计时，它让我问自己：“这些数据做得怎么样才能得到如此糟糕的待遇呢？” 数据持续时间长于代码，因此应对其进行处理。

在我不断寻求帮助你尊重你的数据库的过程中，我想从今天开始指出你做错了什么。你以后会感谢我的。

以下是您在设计数据库时不会想做的七件事。

1.自己动手

像牙科一样，数据库设计最好留给专业人士，而不是你应该为自己做的事情。我不在乎你是否能够在最后用一个花哨的镜子拿到其中一个探头，你应该停止在嘴里塞一些锋利的东西。

仅仅因为你可以做某事并不意味着你应该做。如果您之前没有设计过数据库，那么就不要将任务关键型系统作为您的第一个项目。出去聘请专家来帮助指导你。

我认为迪尔伯特总结得很好：

2.没有表现期望

我参与了多个项目，根本没有任何绩效期望。好吧，直到我们投入生产并且“太慢”。如果没有定义可接受的性能水平，那么为了将性能提升到可接受的水平，很难放松几个月的工作。最终的结果是我们部署了一个系统，但没有人对这个过程感到满意。

如果您没有设置任何性能预期，那么在部署的早期阶段您应该会遇到一些令人头疼的问题。同样地，如果你对性能有很大的期望，你应该期待一些失望，特别是如果你没有做过任何压力测试。有可能是十行数据的测试系统并不能很好地表明生产中数百万行的行为。

3.变大，以防万一

我经常看到数据类型被选中，好像它们无关紧要。但事实是（尽管你在大学时被告知的一切）规模很重要。如果您知道某个列的唯一可能值介于0到100,000之间，那么当INT完全正常时，您不需要为该列打一个BIGINT数据类型。为什么这很重要？BIGINT数据类型需要8个字节的存储空间，而INT只需要4个字节的存储空间。这意味着对于每行数据，您可能会浪费4个字节。听起来不是很多，对吗？

那么，让我们考虑你的表有两百万行。将这些行乘以4个字节，您就有800万字节或大约7.8MB的浪费空间。我知道听起来不是很多，是吗？好吧，它加起来很快。我只向您展示了一个列的一个示例，但您的日期列如何？如果您不需要在1900年之前或2079年之后的日历日期，那么SMALLDATETIME很可能对您有用。哦，不要忘记这些列可以编入索引，这些索引也会不必要地更宽。

出于各种原因，选择正确的数据类型很重要。花点时间，努力在开始时做到正确。

4.不检查外键作为索引策略的一部分

当然，我假设你甚至定义了外键。我见过很多数据库，几乎没有主键，外键，甚至任何定义的索引。不，我不知道谁会做这样的事情。但他们在那里，你迟早也会找到它们。

假设你定义了FK，那么你应该进行评估，看看添加索引以匹配那些FK定义是否有意义。在某些情况下，它会。在其他情况下，它不会。但是您应该确保此类审核是整个设计过程的一部分。

事实上，这让我想起了在设计数据库时你不想做的另一件事......

5.索引每列，或索引无列

假设您已经设置了一些实际的性能基准，那么您可能会考虑构建一些索引。如果您没有定义任何索引，那么您可能根本不关心性能。

我大部分时间都看到的是定义了太多索引的数据库。这通常是某人使用索引调整顾问工具的结果，但通常情况下，由于有人在阅读博客文章时说“索引是您需要的”，他们会努力创建十几个索引让一个查询运行得更快。

虽然索引非常适合帮助您更快地读取数据，但它会增加每个DUI语句（删除，更新，插入）的开销。向表中的每个列添加索引可能是任何有数据进入该表的进程的噩梦。

6.忘记数据质量

作为一名DBA，我理解我的角色是专注于恢复。如果系统出现故障，我需要能够快速恢复数据。这是我的主要关注点。数据库设计人员不必担心数据的恢复（因为这是我的工作），而是专注于数据的完整性。

如果您正在设计数据库，那么您需要确保已经考虑了数据质量。你根本不能指望别人为你这样做。想象一下，如果DBA期望其他人负责恢复数据？不幸的是，我曾与许多系统一起工作，这些系统由于被人们称之为“垃圾进入，垃圾出局”而遭到破坏。如果你已经建立了一个依赖完美数据的系统，那么我在这里告诉你，你的系统有一天会很快失败。

有许多方法可以强制执行某种类型的数据完整性。规范化是一种方式。另一种方法是部署数据质量服务等服务。这允许您执行有助于保证一定级别数据质量的规则和约束。

7.无数据保留或存档策略

我愿意打赌你现在拥有超过七年的数据。无论系统如何，七年似乎是每个人都说他们需要的神话中的神话。如果你问某人他们需要多长时间保存任何系统的记录，答案几乎总会回来“七年”，即使真正的答案接近七周。

因此，系统构建时只考虑一件事：始终在表中存储和保存它。很少有人站起来说“嘿，也许我们可以同意超过一年的数据可以归档。” 不可避免地会有人回答“这很好，但是如果我需要在去年运行报告，你最好能够在一小时内收回我的数据。”

如果您正在设计数据库，则需要花时间查找将保留多少数据。知道这些信息可以帮助您在存储越来越多的数据时预测性能预期。

结论

这是我看到好的数据库想法变成糟糕的数据库设计的清单。如果您发现自己正在做这七件事中的任何一件事，那么随着时间的推移，您的数据库设计可能会越来越远离理想状态。简单地避免这七件事就会使数据库随着时间的推移而降低性能。

原文标题《Designing a Database: 7 Things You Don't Want to Do》

作者：Thomas LaRock

译者：February

不代表云加社区观点，更多详情请查看原文链接