从列的类型来看，member 表并不很有趣：所有列中，除了一列之外，其他列都是可变长字符串。这个例外的列就是e x p i r a t i o n，为DATE 型。终止日期值有一个缺省值为“0 0 0 0 - 0 0 -0 0”，这是一个非NULL 的值，它表示未输入合法的日期值。这样做的原因是expiration 可以是NULL，它表示一个会员是终身会员。但是，因为此列可以为NULL，除非另外指定一个不同的值，否则它将取缺省值“ 0 0 0 0 - 0 0 - 0 0”。如果创建了一个新会员记录，但忘了指定终止日期，该会员将成为一个终身会员！通过采用缺省值“ 0 0 0 0 - 0 0 - 0 0”的方法，避免了这个问题。它还向我们提供了一种手段，即可以定期地搜索这个值，以找出过去未正确输入终止日期的记录。
请注意，我们“忘了”放入会员ID 号的列。这是专门为了以后练习使用ALTER TABLE语句而遗留下的。现在让我们来验证一下MySQL是否确实如我们所期望的那样创建了表。在mysql中，发布下列查询：
与MySQL3.23 一样，此输出还包括了显示访问权限信息的另一个列，这里没有给出， 因为它使每行太长，不易显示。
这个输出结果看上去和我们所期望的非常一致，除了state 列的信息显示它的类型为CHAR( 2 )。这就有点古怪了，我们不是定义它为VARCHAR(2) 了吗？是的，是这样定义的，但是MySQL已经悄悄地将此类型从VARCHAR 换成了CHAR。原因是为了使短字符串列的 存储空间利用更为有效，这里不多讨论。如果希望详细了解，可参阅第3 章中关于ALTE RTABLE 语句的介绍。但对这里的使用来说，两种类型没有什么差别。
如果发布一个DESCRIBE member 查询，mysql也会显示member 表的类似信息。DESCRIBE 在您忘了表中的列名、需要知道列的类型、了解列有多宽等的时候很有用。它对于了解MySQL存储表行中列的次序也很有用。列的这个存储次序在使用INSERT 或LOAD DATA 语句时非常
重要，因为这些语句期望列值以缺省列的次序列出。DESCRIBE 可以省写为DESC，或者，如果您喜欢键入较多字符，则DESCRIB Etbl_name 另一个等同的语句为SHOW COLUMNS FROM tbl_name。
如果忘了表名怎么办？这时可以使用SHOW TABLE S。对于samp_db 数据库，我们目前 为止创建了两个表，其输出结果如下：
如果您甚至连数据库名都记不住，可在命令行上调用mysql而不用给出数据库名，然后发布SHOW DATABASES 查询：
数据库的列表在不同的服务器上是不同的，但是至少可以看到samp_db 和mysql；后一个数据库存放控制MySQL访问权限的授权表。DESCRIBE 与SHOW 查询具有可从外壳程序中使用的命令行等同物，如下：
% mysqlshow 与SHOW DATABASES 一样列出所有数据库
% mysqlshow db _ name 与SHOW TABLES 一样列出给定数据库的表
% mysqlshow db_name tbl_name 与DESCRIBE tbl_name 一样，列出给定表中的列 2. 用于学分保存方案的表
为了知道学分保存方案需要什么表，我们来看看在原来学分簿上是怎样记学分的。图1- 2示出学分簿的一页。该页的主体是一个记录学分矩阵。还有一些对学分有意义的必要信息。学生名和ID 号列在矩阵的一端。（为了简单好看，只列出了四个学生。）在矩阵顶端，记录了进行测验和测试的日期。图中示出9月3号、6号、16号和2 3号进行测验， 9月9号和10月1号进
行测试。
为了利用数据库来记录这些信息，需要一个学分表。这个表中应该包含什么记录呢？很明显，每一行都需要有学生名、测验或测试的日期以及学分。图1-3 示出了用这样的表表示的一些来自学分簿的学分。（日期以MySQL的表示格式“Y Y Y Y- M M - D D”表示。）
但是，以这种方式设置表似乎有点问题。好像少了点什么。请看图1- 3中的记录，我们分辨不出是测验的学分还是测试的学分。如果测验和测试的学分权重不同，在确定最终的学分等级时知道学分的类型是很重要的。或许可以试着从学分的取值范围来确定学分的类型（测验的学分一般比测试的学分少），但是这样做很不方便，因为这需要进行判断，而且在数据中也不明显。可以通过记录学分的类型来进行区分，如对学分表增加一列，此列包含“ T”或“Q”以表示是“测试”或是“测验”，如图1-4 所示。这具有使学分数据类型清析易辨的优点。不利的地方是这个信息有点冗余。显然对具有同一给定日期的记录，学分的类型列总是取相同的值。9月2 3日的学分总是为“ Q”类型，而10月1日的学分其类型总是具有“ T”类型。这样令人很不满意。如果我们以这种方式记录一组测验或测试的学分，不仅要为每个新记录输入相同的日期，而且还要一再重复地输入相同的学分类型。谁会希望一再输入冗余的信息呢？
我们可以试试另外一种表示。不在score 表中记录学分类型，而是从日期上区分它们。我们可以做一个日期列表，用它来记录每个日期发生的“学分事件”（测验或测试）。然后可以将学分与这个事件列表中的信息结合，确定学分是测验学分还是测试学分。这只要将score 表记录中的日期与event 表中的日期相匹配得出事件类型即可。图1- 5示出这个表的设计并演示了score 表记录与9月2 3日这个日期相关联的工作。通过将score 表中的记录与event 表中记录相对应，我们知道这个学分来自测验。
这比根据某些猜测来推断学分类型要好得多；我们可以根据明确记录在数据库中的数据来直接得到学分类型。这也比在score 表中记录学分类型更好，因为我们只需对每个类型记录一次。
但是，在第一次听到这种事情时（即结合使用多个表中的信息），可能会想，“嗯，这是一个好主意，但是不是要做很多工作呢？会不会使工作更复杂了？”在某种程度上，这种想法是对的。处理两个记录表比处理一个要复杂。但是再来考察一下学分簿（见图1- 2）。不是也记录了两套东西吗？考虑下列事实：
■ 在学分矩阵中用两个单元记录学分，其中每个单元都是按学生名字和日期（在矩阵的
旁边和顶上）进行索引的。这代表了一组记录；与score 表的作用相同。
■ 怎样知道每个日期代表的事件类型呢？在日期上方写了字符“ T”或“Q”！因此，也在矩阵顶上记录了日期和学分类型之间的关系。它代表第二组记录；与event 表的作用相同。
换句话说，这里建议在两个表中记录信息与用学分簿记录信息所做的工作没什么不同。唯一不同的是，这两组信息在学分簿中不是那么明显地被分开。在图1- 5中所示的event 表的设计中加了一个要求，那就是日期必须是唯一的，因为要用它连接score 与event 表的记录。换句话说，同一天不能进行两次测验，或者同一天不能进行一次测验和一次测试。否则，将会在score 表中有两个记录并且在event 表中也有两个记录，全都具有相同的日期，这时就不知道应如何将score 的记录与event 的记录进行匹配。如果每天不多于一个学分事件，这就是一个永远不会出现的问题，可是事实并非如此简单。有时，一天中可能会有不止一个学分事件。我常听有的人说他们的数据，“那种古怪情况从不会出现。”然而，如果这种情况确实出现时，就必须重新设计表以适应这种情况引起的问题。最好是预先考虑以后可能出现的问题，并预先准备好怎样处理他们。因此，我们假定有时可能会需要同一天记录两组学分。我们怎样处理呢？如果出现这种情况，问题并不难解决。只要对处理数据的方式作一点小的更改，就可使同一日期上有多个事件而不会引起问题：
1) 增加一个列到event 表，并用它来给表中每个记录分配一个唯一的编号。实际上这就给了每个事件一个唯一的ID 号，因此我们称该列为event_id 列。（如果觉得这好像是做傻事，可看一下图1-2 中的学分簿，其中已经有这个特征了。事件ID 正好与学分簿分数矩阵中列号相似。这个编号可能没有清晰地写在那儿并标上“事件ID，”但是它确实在那儿。） 2) 当向score 表中输入学分时，输入的是事件ID 而不是日期。这些改变的结果如图1-6 所示。现在连接score 和event 表时，用的是事件ID 而不是日期，而且不仅用event 表来决定每个学分的类型，而且还用它来决定其日期。并且在event 表中不再有日期必须唯一这个限制，而唯一的是事件ID。这表示同一天可以有一打测试和测验，而且能够在记录里边直接保存它们。（毫无疑问，学生们听到这个一定浑身发抖。）不幸的是，从人的观点来看，图1-6 中的表设计较前一个更不能令人满意。score 表也更为抽象一些，因为它包含的从直观上可以理解的列更少。而图1-4 中此表的设计直观且容易理解，因为那个score 表具有日期和学分类型的列。当前的score 表如图1-6 所示，日期和学分类型的列都没有了。这极大地去除了作为人能够很容易考虑的一切。谁希望看到其中有“事件ID”的score 表？如果有的
MySQL教程
