仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 1027|回复: 8
打印 上一主题 下一主题

[学习教程] 数据库计划中的14个技能

[复制链接]
海妖 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 14:07:10 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
从理论上讲,完全可以为数据表里的每个字段分别建一个索引,但MySQL把同一个数据表里的索引总数限制为16个。1.原始票据与实体之间的干系
能够是一对1、一对多、多对多的干系。在一样平常情形下,它们是一对一的干系:即一张原始票据对应且只对应一个实体。在特别情形下,它们多是一对多或多对一的干系,即一张原始单证对应多个实体,或多张原始单证对应一个实体。这里的实体能够了解为基础表。明白这类对应干系后,对我们计划录进界面年夜有优点。

〖例1〗:一份员工经历材料,在人力资本信息体系中,就对应三个基础表:员工基础情形表、社会干系表、事情简历表。这就是“一张原始单证对应多个实体”的典范例子。

2.主键与外键
一样平常而言,一个实体不克不及既无主键又无外键。在E—R图中,处于叶子部位的实体,能够界说主键,也能够不界说主键(由于它无子孙),但必需要有外键(由于它有父亲)。
主键与外键的计划,在全局数据库的计划中,占据主要位置。当全局数据库的计划完成今后,有个美国数据库计划专家说:“键,各处都是键,除键以外,甚么也没有”,这就是他的数据库计划履历之谈,也反应了他对信息体系中心(数据模子)的高度笼统头脑。由于:主键是实体的高度笼统,主键与外键的配对,暗示实体之间的毗连。

3.基础表的性子
基础表与两头表、一时表分歧,由于它具有以下四个特征:
(1)原子性。基础表中的字段是不成再分化的。
(2)原始性。基础表中的纪录是原始数据(基本数据)的纪录。
(3)归纳性。由基础表与代码表中的数据,能够派生出一切的输入数据。
(4)不乱性。基础表的布局是绝对不乱的,表中的纪录是要临时保留的。
了解基础表的性子后,在计划数据库时,就可以将基础表与两头表、一时表辨别开来。

4.范式尺度
基础表及其字段之间的干系,应只管满意第三范式。可是,满意第三范式的数据库计划,常常不是最好的计划。为了进步数据库的运转效力,经常必要下降范式尺度:得当增添冗余,到达以空间换工夫的目标。

〖例2〗:有一张寄存商品的基础表,如表1所示。“金额”这个字段的存在,标明该表的计划不满意第三范式,由于“金额”能够由“单价”乘以“数目”失掉,申明“金额”是冗余字段。可是,增添“金额”这个冗余字段,能够进步查询统计的速率,这就是以空间换工夫的作法。
在Rose2002中,划定列有两品种型:数据列和盘算列。“金额”如许的列被称为“盘算列”,而“单价”和“数目”如许的列被称为“数据列”。
表1商品表的表布局
商品称号商品型号单价数目金额
电视机29吋2,50040100,000

5.普通地舆解三个范式
普通地舆解三个范式,关于数据库计划年夜有优点。在数据库计划中,为了更好地使用三个范式,就必需普通地舆解三个范式(普通地舆解是够用的了解,并非最迷信最正确的了解):
第一范式:1NF是对属性的原子性束缚,请求属性具有原子性,不成再分化;
第二范式:2NF是对纪录的唯一性束缚,请求纪录有唯一标识,即实体的唯一性;
第三范式:3NF是对字段冗余性的束缚,即任何字段不克不及由其他字段派生出来,它请求字段没有冗余.
没有冗余的数据库计划能够做到。可是,没有冗余的数据库一定是最好的数据库,偶然为了进步运转效力,就必需下降范式尺度,得当保存冗余数据。详细做法是:在观点数据模子计划时恪守第三范式,下降范式尺度的事情放到物理数据模子计划时思索。下降范式就是增添字段,同意冗余。

6.要擅长辨认与准确处置多对多的干系
若两个实体之间存在多对多的干系,则应打消这类干系。打消的举措是,在二者之间增添第三个实体。如许,本来一个多对多的干系,如今变成两个一对多的干系。要将本来两个实体的属性公道地分派到三个实体中往。这里的第三个实体,本色上是一个较庞大的干系,它对应一张基础表。一样平常来说,数据库计划工具不克不及辨认多对多的干系,但能处置多对多的干系。

〖例3〗:在“藏书楼信息体系”中,“图书”是一个实体,“读者”也是一个实体。这两个实体之间的干系,是一个典范的多对多干系:一本图书在分歧工夫能够被多个读者借阅,一个读者又能够借多本图书。为此,要在两者之间增添第三个实体,该实体取名为“借还书”,它的属性为:借还工夫、借还标记(0暗示借书,1暗示还书),别的,它还应当有两个外键(“图书”的主键,“读者”的主键),使它能与“图书”和“读者”毗连。

7.主键PK的取值办法
PK是供程序员利用的表间毗连工具,能够是一无物理意义的数字串,由程序主动加1来完成。也能够是有物理意义的字段名或字段名的组合。不外前者比后者好。当PK是字段名的组应时,倡议字段的个数不要太多,多了不仅索引占用空间年夜,并且速率也慢。

8.准确熟悉数据冗余
主键与外键在多表中的反复呈现,不属于数据冗余,这个观点必需分明,现实上有很多人还不分明。非键字段的反复呈现,才是数据冗余!并且是一种初级冗余,即反复性的冗余。初级冗余不是字段的反复呈现,而是字段的派生呈现。

〖例4〗:商品中的“单价、数目、金额”三个字段,“金额”就是由“单价”乘以“数目”派生出来的,它就是冗余,并且是一种初级冗余。冗余的目标是为了进步处置速率。只要初级冗余才会增添数据的纷歧致性,由于统一数据,大概从分歧工夫、地址、脚色上屡次录进。因而,我们倡始初级冗余(派素性冗余),否决初级冗余(反复性冗余)。

9.E--R图没有尺度谜底
信息体系的E--R图没有尺度谜底,由于它的计划与画法不是唯一的,只需它掩盖了体系需求的营业局限和功效内容,就是可行的。反之要修正E--R图。只管它没有唯一的尺度谜底,其实不意味着能够随便计划。好的E—R图的尺度是:布局明晰、联系关系简便、实体个数适中、属性分派公道、没有初级冗余。

10.视图手艺在数据库计划中很有效
与基础表、代码表、两头表分歧,视图是一种虚表,它依附数据源的实表而存在。视图是供程序员利用数据库的一个窗口,是基表数据综合的一种情势,是数据处置的一种办法,是用户数据保密的一种手腕。为了举行庞大处置、进步运算速率和节俭存储空间,视图的界说深度一样平常不得凌驾三层。若三层视图仍不敷用,则应在视图上界说一时表,在一时表上再界说视图。如许重复交迭界说,视图的深度就不受限定了。

关于某些与国度政治、经济、手艺、军事和平安好处有关的信息体系,视图的感化加倍主要。这些体系的基础表完成物理计划以后,当即在基础表上创建第一层视图,这层视图的列数和布局,与基础表的列数和布局是完整不异。而且划定,一切的程序员,一概只准在视图上操纵。只要数据库办理员,带着多团体员配合把握的“平安钥匙”,才干间接在基础表上操纵。请读者想一想:这是为何?

11.两头表、报表和一时表
两头表是寄存统计数据的表,它是为数据堆栈、输入报表或查询了局而计划的,偶然它没有主键与外键(数据堆栈除外)。一时表是程序员团体计划的,寄存一时纪录,为团体所用。基表和两头表由DBA保护,一时表由程序员本人用程序主动保护。

12.完全性束缚体现在三个方面
域的完全性:用Check来完成束缚,在数据库计划工具中,对字段的取值局限举行界说时,有一个Check按钮,经由过程它界说字段的值城。参照完全性:用PK、FK、表级触发器来完成。用户界说完全性:它是一些营业划定规矩,用存储历程和触发器来完成。

13.避免数据库计划打补钉的办法是“三少准绳”
(1)一个数据库中表的个数越少越好。只要表的个数少了,才干申明体系的E--R图少而精,往失落了反复的过剩的实体,构成了对客不雅天下的高度笼统,举行了体系的数据集成,避免了打补钉式的计划;
(2)一个表中组合主键的字段个数越少越好。由于主键的感化,一是建主键索引,二是做为子表的外键,以是组合主键的字段个数少了,不但节俭了运转工夫,并且节俭了索引存储空间;
(3)一个表中的字段个数越少越好。只要字段的个数少了,才干申明在体系中不存在数据反复,且很少无数据冗余,更主要的是催促读者学会“列变行”,如许就避免了将子表中的字段拉进到主表中往,在主表中留下很多空余的字段。所谓“列变行”,就是将主表中的一部份内容拉进来,别的独自建一个子表。这个办法很复杂,有的人就是不习气、不采取、不实行。
数据库计划的有用准绳是:在数据冗余和处置速率之间找到符合的均衡点。“三少”是一个全体观点,综合概念,不克不及伶仃某一个准绳。该准绳是绝对的,不是相对的。“三多”准绳一定是毛病的。试想:若掩盖体系一样的功效,一百个实体(共一千个属性)的E--R图,一定比二百个实体(共二千个属性)的E--R图,要好很多。
倡始“三少”准绳,是叫读者学会使用数据库计划手艺举行体系的数据集对于update操作,event中依次记录旧行,新行的值。
乐观 该用户已被删除
沙发
发表于 2015-1-18 12:04:35 来自手机 | 只看该作者
同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中,就能感觉到目前架构的尴尬。
若相依 该用户已被删除
板凳
发表于 2015-1-26 12:50:43 | 只看该作者
从底层原理到表层引用,书籍多的很。个人认为没有什么那本书好?这样的说法。主要看和个人的学习方法是否适合。
飘灵儿 该用户已被删除
地板
发表于 2015-2-4 18:35:17 | 只看该作者
而写到本地,我又考虑到效率问题.大家来讨论讨论吧,分数不打紧,就给10分,十全十美,没啥对错,各抒己见,但是要有说服力的哦~
冷月葬花魂 该用户已被删除
5#
发表于 2015-2-10 05:44:02 | 只看该作者
换言之,只有在不断的失败中尝试成功,而关于失败的总结却是很少的
分手快乐 该用户已被删除
6#
发表于 2015-2-28 23:01:25 | 只看该作者
入门没那么困难,精通没那么容易
兰色精灵 该用户已被删除
7#
发表于 2015-3-10 10:18:14 | 只看该作者
现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层.
灵魂腐蚀 该用户已被删除
8#
发表于 2015-3-17 06:45:29 | 只看该作者
XML字段类型更好的解决了XML数据的操作。XQuery确实不错,但是个人对其没好感。(CSDN的开发者应该是相当的熟了!)
admin 该用户已被删除
9#
发表于 2015-3-24 00:57:59 | 只看该作者
多加的系统视图和实时系统信息这些东西对DBA挑优非常有帮助,但是感觉粒度还是不太细。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-4-27 19:28

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表