What can go wrong

这章从生活中举例来说明一些基本问题，这些问题出现在当数据存储在一些设计糟糕的数据库表。这些都是我在设计工作中真是的案例。它们不是课本或考试卷里的。出于保密的原因，我移除和修改了一些数据。

一、错误地处理关键字和分类

• 一个设计数据库很常见的问题就是没有合适地使用关键字和分类。许多数据库程序都有自己对数据的分类方法：产品或事件可能对某些种类的人，通过年龄、兴趣或收入（或者三者）对客户分类。当填充数据的时候，你可能还想着它特别的关键字或类型列表。然而，当你准备报告或分析活动时，你可能得从其他角度看待事物。你通常想看看一个类型的列表包含哪些东西、或者列表包含了多少东西。例如，你会问：“我们高收入群体占多大比重？”如果关键字和分类起初没有正确地存储，这些报告会很难写出来。
• 例1.1描述了一个场景，关于植物的数据是怎么被使用的。乍一看没问题的，很合理，但是最后发现，实际上根本和你预期的不一样。

例1.1：下面的表记录的是一些植物的特征，帮助那些种植户决策这些植物是否符合他们的要求。

课外知识：
第一行是：种类、物种、俗名、用途
第一列是：车桑子、雪松*5

如果我们查询一种植物，可以快速得知它的用途。但是我们想找到所有适合用作hedging的植物时就会遇到困难。我们需要分别搜索每列。要找到合适的信息，需要满足逻辑：IF Usage1 = ’ hedge ’ OR Usage2 = ’ hedge ’ OR Usage3 = ‘对冲’。此外，数据库表本身限制了植物只有三种用途。目前这可能已经足够了，但是如果要增加用途，将不得不重新设计表，以包含一个新的列。查询逻辑也要修改，Usage4 = ’ hedge '… 在内心深处，我们知道无论我们决定使用多少种用途，最终我们都会遇到一种会产生更多要求的植物。
这么描述有点太乏味了，数据库无法维护。虽然这张表成功地提供了每一种植物的信息，但它并不能满足潜在的需求，为种植户提供合适的植物。我们认认真真为植物收集的关于Usage的信息，失去了可用性。

---

在例1.1中，让人不好意思的是，所有数据都完整的收录，但是表的设计让人不能很方便地访问到需要的数据。而且开发人员也不能回过头来重新考虑数据用途。他设计这个表主要是为了解决他当时的问题，即他要把所有他知道的关于那些植物的信息都存储起来。实际上，在动手前好好考虑一下这些数据的潜在用途是很有用的。最明显的一条就是：我要找到所有拥有这个用途的植物。
开发人员片面的观点导致了不合适的数据模型。他仅仅通过单一的类型看待植物数据，把用途看成植物的一个属性，把种属和俗名也是一样。如果你仅仅是要知道某种植物有什么特点的话，这么做是OK的。但是你要通过某些特点区搜索一些植物就会遇到麻烦。
在这个例子，我们有两个重要数据，植物和用途（Usage），我们想知道它们之间的联系。《建模技巧》在书中描述了一些办法，你从数据真正想得到什么信息以及如何通过设计最优的数据库来帮你解决这个问题。
往前走两步，咱们看看怎么解决植物数据库的问题。你可以很快从图1.2中看到，建两张关联表。（在第二章你会看到，额外建表可能会让你的工作更美好。）

一个有点数据库经验的用户会建立合适的主键，关联关系和联结来写报告。一个在Usage表中的简单查询会确保用户搜索到所有用途为hedging的植物。现在一个植物有什么usage咱们还没有进行约束。这里咱们一开始的设置比例1.1会更加的消耗资源和时间，但是咱们比它做的更好。
例1.1让我们看到了什么样的设计是糟糕的，虽然它也有优点。所以我们知道了分类和主键是没那么容易设计的。

---

例1.2 研究兴趣

大学的宣传部的一个员工收到了很多电话，要求和一个专家在某些话题进行探讨。大学的人事部门数据库根本没有这方面的信息，所以他们决定再建个表，存储每个员工的主要研究兴趣。起初，计划是记录员工一个主要的兴趣，不强迫人家。兴趣数量有多少是含糊不清的，他们决定通过在表里添加列来解决。看下面的表。

看出问题来了没，咱们怎么解决？我是个专家，我一看就知道，这个表找一个人有什么兴趣很简单，但你要找出有兴趣A的所有人就会很尴尬。和例1.1一样，这个表设计的不好，只是根据人来分类。但是我们有两个重要的属性，人和兴趣，而且这两个属性之间有密切关系。所以例1.1是怎么解决问题的，例1.2也适用。
给People建一个简单的表不难，但是这个兴趣表的“姿势”该怎么摆呢？在例1.1中，Usage很容易区分，hedging、shleter等等。那例1.2中，这些兴趣怎么区分呢？答案不是很明显。再看看表，一共看到8个兴趣，这些兴趣的的确确不容易区分出来。

二、重复信息
三、为单独的报告设计
四、总结