设计数据库:7件你不想做的事情

你的数据库设计很糟糕。

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

嗯，我关心糟糕的设计，因为我通常承担着让查询运行得很快并克服糟糕设计的限制的重担。作为一名数据专业人员，在过去的15年里，我见证了(并构建了)我的数据库设计分享。有些很好，有些还不错，但大多数都让我想用裁纸刀捅人。

当我遇到一个不好设计时，我就会问自己:“这些数据做了什么，竟然会受到如此恶劣的对待?” ，数据比代码持续的时间更长，因此应该相应地进行处理。

下面是在设计数据库时不希望做的七件事。

1.自己动手

和牙科一样，数据库设计最好留给专业人员，而不是你应该自己做的事情。我不管你是否能得到一个探针，在末端有一个漂亮的镜子，你应该停止把尖锐的东西塞进你的嘴里。

你能做某件事并不意味着你应该做。如果您以前没有设计过数据库，那么不要将关键任务系统作为您的第一个项目。出去雇一个专家来指导你。

我认为下面总结得好:

2. 没有性能预期

我参与过不止一个项目，在这些项目中根本没有任何性能期望。好吧，直到我们投入生产，它“太慢了”。如果没有定义一个可接受的性能水平，就很难放松几个月的工作，以使性能达到可接受的水平。最终的结果是我们部署了一个系统，但没有人对这个过程感到满意。

如果您没有设置任何性能期望，那么您应该在部署的早期阶段就会遇到一些麻烦。同样的，如果你对工作表现有很大的期望，你应该期待一些失望，特别是如果你没有做任何压力测试。10行数据的测试系统很可能并不能很好地说明生产环境中数百万行的行为。

3. 大一点，以防万一

我经常看到选择数据类型就好像它们不重要一样。但事实是(不管你在大学里被告知了什么)大小很重要。如果您知道某一列的唯一可能值在0到100,000之间，那么当INT可以很好地处理该列时，就不需要对该列使用BIGINT数据类型。为什么这很重要?BIGINT数据类型需要8字节的存储，INT只需要4字节的存储。这意味着对于每一行数据，您可能会浪费4字节。听起来并不多，对吧?

好吧，我们假设你的表有200万行。将这些行乘以4个字节，就会有800万字节，或大约7.8MB的浪费空间。我知道听起来不是很多，是吗?好吧，加起来很快。我只向您展示了一列的一个示例，但是您的日期列呢?如果你不需要在1900年之前或2079年之后的日历日期，那么SMALLDATETIME可能很适合你。哦，别忘了这些列可以被索引，而且这些索引也会不必要地更宽。

出于各种原因，选择正确的数据类型非常重要。花点时间，努力在一开始就把它做好。

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

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

假设您已经定义了FK，那么您应该进行评估，看看是否有必要添加索引来匹配这些FK定义。在某些情况下，它会的。在其他情况下，它不会。但是您应该确保这种类型的审查是您整个设计过程的一部分。

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

5. 索引每一列，或不索引任何列

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

我经常看到的是定义了太多索引的数据库。这通常是由于有人使用优化索引advisor工具但它通常可以的情况是由于有人阅读一篇博客文章中说,“索引是你需要什么”,他们着手创建一打索引以获得一个查询运行得更快。

虽然索引可以帮助您更快地读取数据，但是它会为每个DUI语句(删除、更新、插入)增加开销。对于任何有数据进入该表的进程来说，向表中的每一列添加索引都可能是一场噩梦。

6. 忘记了数据质量

作为一名DBA，我明白我的职责是专注于恢复。如果系统崩溃，我需要能够恢复数据，而且速度快。这是我的主要关注点。数据库设计人员不必担心数据的恢复(因为这是我的工作)，而是关注数据的完整性。

如果您正在设计一个数据库，那么您需要确定您已经考虑到了数据质量。你不能指望别人为你做这些。想象一下，如果DBA希望其他人负责恢复数据，会发生什么情况?不幸的是，我曾经使用过很多系统，它们都因为被亲切地称为“垃圾输入，垃圾输出”而停机。如果你已经建立了一个依赖于完美数据的系统，我在这里告诉你你的系统有一天会崩溃，很可能很快。

有很多方法可以实现某种类型的数据完整性。归一化是一种方法。另一种方法是部署服务，比如数据质量服务。这允许您强制执行规则和约束，以帮助保证一定级别的数据质量。

7. 没有数据保留或归档策略

我敢打赌，您现在的磁盘上有超过7年的数据。七年似乎是沙中的神话线，每个人都说他们需要，不管什么制度。如果你问某人需要为任何系统保存记录多长时间，答案几乎总是“七年”，即使真正的答案接近七周。

因此，系统构建时只考虑一件事:将其存储并永久保存在表中。很少有人会站起来说:“嘿，也许我们可以同意，一年以上的数据可以存档。”不可避免地有人会说:“没关系，但如果我需要做上一年的报告，你最好能在一小时内得到我的数据。”

如果您正在设计一个数据库，那么您需要花费时间来确定究竟会保留多少数据。当存储越来越多的数据时，了解这些信息将帮助您实现项目性能预期。

结论

这就是我看到好的数据库创意如何变成糟糕的数据库设计的清单。如果您发现自己在做这7件事情中的任何一件，那么随着时间的推移，您的数据库设计将越来越偏离理想。简单地避免这七件事将使您的数据库在一段时间内不会出现性能下降。