MySQL教程

    (3) 创建表
    现在我们已经作好了创建历史同盟表的准备。我们用CREATE TABLE 语句来完成这项工作，其一般格式如下：

    其中tbl_name 代表希望赋予表的名称。column_specs 给出表中列的说明，以及索引的说明（如果有的话）。索引能使查找更快；我们将在第4 章“查询优化”中对其作进一步的介绍。
president 表的CREATE TABLE 语句如下所示：

    如果想自己键入这条语句，则调用mysql，使samp_db 为当前数据库：

    然后，键入如上所示的CREATE TABLE 语句。（请记住，语句结尾要增加一个分号，否则mysql将不知道哪儿是语句的结尾。）
为了利用来自样例数据库分发包的预先写下的描述文件来创建president 表，可从外壳程序运行下列命令：

    不管用哪种方法调用mysql，都应该在命令行中数据库名的前面指定连接参数（主机名、用户名或口令）。CREATE TABLE 语句中每个列的说明由列名、类型（该列将存储的值的种类）以及一些可能的列属性组成。president 表中所用的两种列类型为VARCHAR 和DATE。VARCHAR（n）代表该列包含可变长度的字符（串）值，其最大长度为n 个字符。可根据期望字符串能有多长来选择n 值。
state 定义为VARCHAR( 2 )；即所有州名都只用其两个字符的缩写来表示。其他的字符串列则需要更长一些，以便存放更长的值。
我们使用过的其他列类型为DATE。这种列类型表示该列存储的是日期值，这一点也不令人吃惊。而令人吃惊的是，日期的表示以年份开头。其标准格式为“ Y Y Y Y- M M - D D”（例如，“1999 - 07 - 18”）。这是日期表示的ANSI SQL 标准。我们用于president 表的唯一列属性为NULL（值可以缺少）和NOT NULL（必须填充值）。多数列是NOT NULL 的，因为我们总要有一个它们的值。可有NULL 值的两个列是s uff i x（多数姓名没有后缀）和death（有的总统仍然健在，所以没有死亡日期）。member 表的CREATE TABLE 语句如下所示：

    将此语句键入mysql或执行下列外壳程序命令：

    从列的类型来看，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不适合我？”正如您所猜测的那样，笔者将从否定的方面对这个问题进行回答，否则这本书就没必要再往下写了。不过，在考虑如何做一件工作时，应考虑各种情况并提问是否最好不使用数据库系统（如MySQL）而使用一些别的东西（如电子表格等）：
    ■ 学分簿有行和列，而电子表格也有。这使学分簿和电子表格在概念上和外观上都非常类似。
    ■ 电子表格能够完成计算，可以利用一个计算字段来累计每个学生的学分。但是，要对测验和测试进行加权可能有点麻烦，但这也是可以办得到的。另一方面，如果希望只查看某部分数据（如只查看学分或测试），进行诸如男孩与女孩的比较，或以一种灵活的方式显示合计信息等，情况又大有不同了。电子表格的功能显得要差一些，而关系数据库系统完成这些工作相当容易。另外要考虑的一点是为了在关系数据库中进行表示而对数据进行抽象和分解，这个问题并不真的那么难以应付。只要考虑安排数据库使其不会以一种对您希望做的事无意义的方式来表示数据即可。但是，在确定了表示方式之后，就要靠数据库引擎来协调和表示数据了。您肯定不会希望将它视为一堆支离破碎的东西。
    例如，在从score 表中检索学分时，不希望看到事件ID；但希望看到日期。这没有什么问题。数据库将会根据事件ID 从event 表中查找出日期。您还可能想要看看是测验的学分或测试的学分。这也不成问题。数据库将用相同的方法查找出学分类型，也是利用事件ID。请记住，这就是如像MySQL这样的关系数据库的优势所在，即，使一样东西与另一样东西相关联，以便从多个来源得出信息并以您实际想看到的形式提供出来。在学分保存数据的情况中，MySQL确实利用事件ID 将信息组合到了一起，而无需人工来完成这件事。
现在我们先来看看，如何使MySQL完成这种将一个东西与另一个东西相联系的工作。
    假定希望看到1999年9月2 3号的学分，针对某个特定日期中给出的事件的学分查询如下所示：

    相当吓人，是吗？这个查询通过将score 表的记录与event 表的记录连接（关联）来检索学生名、日期、学分和学分的类型。其结果如下所示：

    您肯定注意到了，它与图1-4 中给出的表设计相同，而且不需要知道事件ID 就可得出这个结果，只需指出感兴趣的日期并让MySQL查找出哪个学分记录具有该日期即可。如果您一直担心抽象和分解会使我们损失一些东西的话，看到这个世界，就不会有这种担心了。
当然，在考虑过查询后，您还可能对其他别的东西产生担心。即，这个查询看上去有点长并且也有点复杂；是不是做了很多工作写出这样的东西只是为了查找某个给定日期的学分？是的，确实是这样。但是，在每次想要发布一个查询时，有几种方法可以避免键入多行的SQL。一般情况下，一旦您决定如何执行这样一个查询并将它保存起来后，就可以按需要多次执行它。我们将在1. 5节“与mysql交互的技巧”中介绍怎样完成这项工作。
    在上述查询的介绍中，我们有点超前了。不过，这个查询比起我们要实际用来得出学分的查询是有点简单了。原因是，我们还要对表的设计作更多的修改。我们将采用一个唯一的学生ID，而不在score 表中记录学生名。（即，我们将使用来自学分簿的“ ID”列的值而不是来自“ Name”列的值。）然后，创建另一个称为student 的表来存放name 和student_id 列（见图1- 7）。

    为什么要作出这种修改呢？只有一个原因，可能有两个学生有相同的名字。采用唯一的学生ID 号可帮助区分他们的学分。（这与利用唯一的事件ID 而不是日期来分辨出相同日期的测试或测验完全类似。）在对表的设计作了这样的修改后，实际用来获得给定日期的学分查询变得更为复杂了一些，这个查询如下：

    如果您不能立即清楚地读懂这个查询的意思的话，也不必担心。在进一步深入这个教程之后，就能看懂这个查询了。将会从图1- 7中注意到，在student 表中增加了点学分簿中没有的东西。它包含了一个性别列。这便可以做一些简单的事情，如对班级中男孩和女孩的人数计数；也可以做一些更为复杂的事情，如比较男孩和女孩的学分。我们已经设计完了学分保存的几乎所有的表。现在只需要另外
一个表来记录出勤情况即可。这个表的内容相对较为直观，即，一个学生ID 号和一个日期（见图1- 8）。表中的每行表示特定的学生在
给定的日期缺勤。在学分时段末，我们将调用MySQL的计数功能来汇总此表的内容，以便得出每个学生的缺勤数。

上一页  [1] [2] [3] [4] [5] [6] [7] 下一页