关于SQL Server数据库设计的感悟
转载自:http://www.cnblogs.com/leonbao/archive/2008/03/07/1094821.html
关于SQL Server数据库设计的感悟,请指教
有问题的时候,我经常回来博客园寻找答案,久而久之,总结了一些东西。
妄自菲薄,请大家多指出错误,并给出意见
数据库设计三范式基本原则
第一范式:数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。
也就是说,绝对不要出现下面的情况
学生信息
一年一班,97001,张三
这个很容易做到吧,呵呵。
第二范式:数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。
也就是说,绝对不要出现下面的情况
学号
姓名
年龄
课程名称
成绩
学分
97001
张三
13
化学
88
2
其中学号和课程名称是联合主键
因为:
(课程名称) → (学分)
(学号) → (姓名, 年龄)
第三范式:在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系:
关键字段 → 非关键字段x → 非关键字段y
也就是说,绝对不要出现下面的情况
学号
姓名
年龄
所在学院
学院地点
学院电话
97001
张三
13
清华
中关村
8888888
因为:(学号) → (所在学院) → (学院地点, 学院电话)
特别注意:有时为了提高效率,第三范式可以被打破!多见于外键特别多而且数据量巨大的表。为了提高查询的效率,可以牺牲增删改的效率。
关于表、视图、存储过程:
表就是用来存储数据的,要尽量满足三个范式,不要出现冗余的东西。
视图是用来查询数据的,对于没有外键的基础表,可以直接用来查询。对于外键比较多的业务表,查询操作全部要通过视图。
存储过程和触发器我基本不用,我倾向于在数据库层面不要体现太多的业务(甚至不体现),我把业务全部集中在代码层面。其实还有另外一个原因,我不太精通这方面的技术,见谅见谅。
关于索引:
有朋友举过很好的一个例子,聚合索引就像拼音检索,非聚合索引就像部首索引。
拼音索引在整个字典中都是排好序的,就像查英文单词,你只要按照每页角上的英文索引就可以向
相关文档:
系统环境:Windows 7
软件环境:Visual C++ 2008 SP1 +SQL Server 2005
本次目的:编写一个航空管理系统
这是数据库课程设计的成果,虽然成绩不佳,但是作为我用VC++ 以来编写的最大程序还是传到网上,以供参考。用VC++ 做数据库设计并不容易,但也不是不可能。以下是我的程序界面,后面 ......
执行数据操作时,由于拼接SQL存在种种弊端,早就应该抛弃了,但在现实开发时,又由于种种原因,公司一直采用这种方式(UI层和逻辑层都有严格的过滤,倒也没出现过什么问题),但昨天开发时却出现了意想不到的问题,一个简单的语句会造成严重后果。简单的语句示例如下:
/// <summary>
&nb ......
本文节选自MSDN的文章《五种提高 SQL 性能的方法》,提出如何提高基于SQL Server应用程序的运行效率,非常值得推荐。对一些Traffic很高的应用系统而言,如何提高和改进SQL指令,是非常重要的,也是一个很好的突破点。
*文章主要包括如下一些内容(如感兴趣,请直接访问下面的URL阅读完整的中英文文档):
1, 从 INSE ......
固定长度(char)与可变长度(varchar)字符数据类型
char[(n)]
长度为n个字节的固定长度且非Unicode的字符数据。n必须是一个介于1和8,000之间的数值。存储大小为n个字节。char在SQL-92中的同义词为character。
varchar[(n)]
长度为n个字节的可变长度且非Unicode的字符数据。n必须是一个介于1和8,000之间的数值。存储大小为 ......