现了学生和课程之间的多对多关系，当然，这个关系还可以加点额外的东西，比如给StudentCourse表中加AccessLevel字段，值域D{只读,完全,禁止}，就可以实现访问级别。 约定俗成的字段名前/后缀
数据库开发的时间久了，慢慢就会摸索出一个规律来：就是很多的字段都有些共同的特性。比如说，有的字段是代表时间的(例如发帖时间，评论时间)，有的是代表数量的(例如浏览数，评论数)，有的是代表真假类型的(例如是否将博客随笔显示在首页)。对于这种同一类型的字段，应该使用统一的 前缀 或者 后缀去标识它。
我们来举几个例子看得更明白一点。
以大家都熟悉的论坛来说，需要记录会员最后一次登录的时间，这时候一般人都会把这个字段命名为LoginTime 或者 LoginDate。这时候，已经产生了一个歧义：对于另一名开发者来说，如果仅看表的字段名称，不去看表的内容，很容易将LoginTime理解成 登录的次数，因为，Time还有一个很常用的意思，就是次数。
为了避免这种情况发生，应该明确的规定：所有表示时间的字段，统一以 Date 来作为结尾。
我们经常需要统计发帖数、回帖数信息，这时候，开发人员通常会这样去命名字段：PostAmount、PostTime、PostCount，同样，由于Time的歧义，我们首先排除掉不使用PostTime作为字段名。接下来，Amount 和 Count 都可以表示计数的意思，用哪个合适呢？这里，我推荐使用Count。为什么呢？如果你做过Asp开发，相信一定知道 RecordCount 这个属性，命名的时候有一个原则：就是使用约定俗成的名称，而不要去自创名称。既然微软都用Count后缀来表示数目，我们为什么不呢？
于是，所有表示数目的字段，都应该以Count作为结尾。将这一概念做以推广，很容易得出，浏览次数为 ViewCount，登录次数为LoginCount 等等。
再举一个例子，我们很少在数据库里直接保存图片等二进制数据，通常是仅保存图片的URL路径；在文章管理系统中，如果是转载文章，也会用到记录文章出处的字段。个人建议所有代表链接的字段，均为Url结尾。于是，图片路径的字段命名为 ImageUrl，文章出处字段的命名为SourceUrl。
最后一个例子，我们经常需要用到布尔值，比方说，这篇随笔要不要显示到首页，这篇随笔是不是保存到草稿箱等等。同样，按照微软的建议，布尔类型的值均以 Is、Has 或者 Can开头。
如果让我来建表示是否将随笔放到首页的字段，它的名字一定是这样的：IsOnIndex
类似的例子是很多的，我在这里仅举出典型的几个范例，大家可以自行拓展，如果我能起到一个抛砖引玉的作用就很满足了。
字段命名时需注意的一个问题
我发现有很多开发人员喜欢给字段加上表名作为它的前缀，举个例子，如果有个表叫User，那么他就会将这个表中的字段命名为：UserId、UserPassword、UserName、UserPhone 等等。个人认为，这是没有必要的，因为你已经确切的知道了这个表存储的是User的信息，那么其中的字段必然是针对于User的。而且，在Join连接操作中，你的SQL代码看上去也会更加的精简一些，诸如 [User].UserName = Aritcle.ArticleAuthor 这样的代码完全可以实现为 [User].Name = Article.Author。
这里还存在一个特例，就是表的外键包含的字段。在这种情况下，我倾向于使用表名+ID 的方式，比如 CategoryId 、UserId 等。假设有表Article，那么它的主键我会命名为Id，关联用户表User的外键包含的字段，我会命名为UserId。之所以这样，是因为在语言(比如C#)中创建对象时，有时候会使用代码生成器(根据数据库的字段名生成对象的字段、属性名)，此时生成的代码更规整一些。
建表时需要注意的问题
数据库不仅是用来保存数据，还应负责维护数据的完整性和一致性
我看过很多的开发人员设计出来的数据库，给我的感觉就是：在他们眼里，数据库的作用就如同它的名称一样 仅仅是用来存放数据的，除了不得不建的主键以外，什么都没有...没有 Check约束，没有索引，没有外键约束，没有视图，甚至没有存储过程。
在这里，我提出如下数据库设计的建议：
- 如果要写代码来确保表中的行都是唯一的，就为表添加一个主键。
- 如果要写代码来确保表中的一个单独的列是唯一的，就为表添加一个约束。
- 如果要写代码确定表中的列的取值只能属于某个范围，就添加一个Check约束。
- 如果要写代码来连接 父－子 表，就创建一个关系。
- 如果要写代码来维护“一旦父表中的一行发生变化，连带变更子表中的相关行”，就启用级联删除和更新。
- 如果要调用大量的Join来进行一个查询，就创建一个视图。
- 如果要逐条的写数据库操作的语句来完成一个业务规则，就使用存储过程。
NOTE：这里我没有提到触发器，实践证明触发器会使数据库迅速变得过于复杂，更重要的是触发器难以调试，如果不小心建了个连环触发器，就更让人头疼了，所以我更倾向于根本就不使用触发器。
以Not Null的思路建表
我发现很多开发人员在建表的时候，如果要新建一个字段，他的思路是这样的：默认这个字段是可以为Null的，然后去判断是不是非要Not Null不可，如果不是这样，OK，这个字段可以为Null，接着继续进行下一个字段。结果往往是一张表除了主键以外所有的字段都可以为Null。
之所以会有这样的思路，是因为Null好啊，程序不容易出错啊，你插入记录的时候如果不小心忘输了一个字段，程序依然可以Run，而不会出现 “XX字段不能为Null”的错误消息。
但是，这样做的结果却是很严重的，也会使你的程序变得更加繁琐，你不得不进行一些无谓的空值处理，以避免程序出错。更糟的是，如果一些重要数据，比如说订单的某一项值为Null了，那么大家知道，任何值与Null相操作(比如加减乘除)，结果都是Null，导致的结果就是订单的总金额也为Null。
你可以运行下面的代码尝试一下：
Select Null + 5 As Result
你可能会说，就算我将字段设置成Not Null，但是它依然可以接受空字符串，这样一来在程序中还是要进行空值处理。请别忘了，数据库还赋予你一个强力武器，就是 Check 约束，当你需要确保一个字段既不可以为Null，又不可以为空的时候，可以这么写：
ColumnName Varchar(50) Not Null Constraint ck_ColumnName Check(Len(ColumnName) > 0)
所以，合理的思维方式应该是这样的：默认这个字段是 Not Null的，然后判断这个字段是不是非为Null不可，如果不是这样，OK，这个字段是Not Null的，进行下一个字段。
一个建表的范例脚本
个人空间的表的建立，其中的文章表是这样写的：
Create Table Article
(
Id Int Identity(1,1) Not Null,
Title Varchar(50) Not Null Constraint uq_ArticleTitle Unique,
Keywords Varchar(50) Not Null,
Abstract Varchar(500) Not Null,
Author Varchar(50) Not Null Default '张子阳',
Type TinyI