SQL Server数据库学习笔记-设计表时应该考虑的因素

设计数据库其实就是设计数据库中的表。到底要注意些什么才能够设计好一个数据库呢?一个宗旨,8个建议。

一个宗旨“尽量少的表,每个表中尽量少的列,合理的表结构”。

8个建议:

第一个,首先要考虑的是咱们这个数据库的主要作用是什么?至少包含哪些数据?这些数据又分别属于哪些实体对象?对象之间又存在什么样的关系?比如说新闻文章管理系统的数据库,它要存放的数据至少包括:文章分类、文章标题、发文时间、作者;而既然是管理系统,那么肯定会有人要添加、删除或修改文章,那么就延伸出管理员,有管理员了就存在账号、密码;如果还要有对文章的评论功能,那就还得有评论的标题、评论的内容、评论人姓名、评论时间等。这么多需要存放的数据,如何归类?归类后又如何整理相互之间的关系呢?这就需要用到工具。

第二,E-R模型。建立E-R模型的工具很多,甚至纸、笔也算是一种工具。E-R图的画法很多,它的主要作用是将所有要存入数据库的数据归类、整理成一个个的分类,这个分类被称为实体,而被归入这个分类的数据则被称之为实体的属性。不同的实体之间存在关联,比如文章和管理员之间就存在谁发布了文章,文章和评论之间存在某条评论是属于哪篇文章这样的关系,在E-R模型上就必须把这些关系体现出来。

第三,每个实体就是一个表,而实体的属性就是这个表的列,那么问题就出来了,到底什么样的列该用什么样的数据类型,比如文章的标题就该用什么数据类型呢?假如说用NChar(50),接着来看文章标题用NChar(50)保存有没有问题。首先我们说什么情况下用NChar类型呢?一是在在Unicode字符的时候用N开头的类型,其次只有在数据长度基本差不多的情况下采用。但是文章的标题每一个都会是固定长度吗?而且char类型最致命的一个却显示,只要用他的数据、只要长度不够,就自动填充空格。问题就出来了,如果连续10万行数据的这一列都只有40个字符,那么每行增加10个空格,这样下来10万*10字符的空间实际上就白白地被占用了。数据库的体积越大,处理数据的效率必然受影响。再比如说用户注册年龄的问题,肯定首选tinyint,因为目前的人类的年龄不可能超过255岁,而这个类型只占1字节的空间,如果习惯性地用int类型,咋一看也没有问题,只是白白浪费了3个字节的空间,因为int是4字节的长度。总结一下,不浪费空间,也不过分节约空间,适量而行。

第四,允许为空和默认值。这是什么意思呢?首先要明确什么是空值,什么是默认值。这里的空值既不是0也不是空字符,而表示未知,用null表示。这就有问题了,首先,如果处在变长类型列中的null值本身虽然不占空间,但是它所在的列却实实在在地占用空间的。再则null比较特殊,数据库要对null字段进行额外的操作,所以如果表中有较多的null字段时会影响数据库的性能;还有一点是我们现在想不到但将来一定遇到的,null字段会给编程带来一些不大不小的麻烦,比如制造一些bug。所以,一句话,尽量少用允许列为空,如果一定要允许也尽量将之靠后。遇到用户可能不愿意填或乱填的情况,就要用到默认值。比如说用户的注册时间。

第五,主键的问题。每张表都需要一个主键,用来标识唯一的一条数据。

第六,约束和规则。用于确保数据的完整有效性,一旦定义了约束的规则,那么中有满足这些条件的数据才可以插入数据库。比如要求注册会员的性别要么是男,要么是女,绝对不允许第三种情况,再比如年龄只能是18~80岁,其他注册不了。

第七,外键关系。设置外键可以节省空间,方便编程和程序的扩展。

第八,考虑是否使用索引。索引也是一种数据库对象,于是在哪些列上使用索引,对哪些列不适用索引;是使用聚簇索引还是非聚簇索引;是否使用全文索引等等。很多问题需要认真地思考。

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。