database - 数据库设计/使用容易忽略的细节
2,数据类型尽量小,预测可以满足未来需求
3,尽量建表时字段不允许为null,除非必要,可以用NOT NULL+DEFAULT代替
当你需要查询数据的时候你往往需要在WHERE条件中多加一个判断条件IS NOT NULL,这样的一个条件不仅仅增加了额外的开销,而且对查询的性能产生很大的影响,有可能就因为多了这个查询条件导致你的查询变的非常的慢;还有一个比较重要的问题就是允许为空的数据可能会导致你的查询结果出现不准确的问题,
----如果整形字段可以赋0,字符型可以赋值空(这里只是给建议)这里的空和NULL是不一样的意思--增加整形字段可以这样写ALTER TABLE TABLE_NAME ADD COLUMN_NAME INT NOT NULL DEFAULT(0)--增加字符型字段可以这样写ALTER TABLE TABLE_NAME ADD COLUMN_NAME NVARCHAR(50) NOT NULL DEFAULT(‘‘)
4,少用TEXT和IMAGE,二进制字段的读写是比较慢的,而且,读取的方法也不多,大部分情况下最好不用
5,建立自增列时单独再给自增列添加唯一约束
如果要保证ID是唯一的,单单只设置自增值不行,需要给字段设置主键或者唯一约束
6,建立索引
可以根据功能和性能的需求进行初步的索引设计,这里需要根据预计的数据量和查询来设计索引
A、根据数据量决定哪些表需要增加索引,数据量小的可以只有主键
B、根据使用频率决定哪些字段需要建立索引,选择经常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候选字段
C、把经常一起出现的字段组合在一起,组成组合索引,组合索引的字段顺序与主键一样,也需要把最常用的字段放在前面,把重复率低的字段放在前面
D、一个表不要加太多索引,因为索引影响插入和更新的速度
建立索引后,并不是每个查询都会使用索引,在使用索引的情况下,索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引,索引的选择和使用方法是SQLSERVER的优化器自动作的选择,而它选择的根据是查询语句的条件以及相关表的统计信息,这就要求我们在写SQL语句的时候尽量使得优化器可以使用索引。
二、编码
1,查询条件不要使用计算列
例:查询条件为 year(createdate)=2014
优化:createdate>=‘20140101‘ and createdate<=‘20141231‘
原因:使用计算列查询,是通过[索引扫描]方式查找
不使用计算列,走的是索引查找
绝大部分情况下索引查找的查询性能要高于索引扫描,特别是查询的数据库不是非常大的情况下,索引查找的消耗时间要远远少于索引扫描的时间,相关知识[聚集、非聚集、堆的索引]
2,分组统计时避免使用count(*)
if OBJECT_ID(‘Customer‘) is not null drop table [Customer]gocreate table [Customer] (CId int not null,Name nvarchar(20));goif OBJECT_ID(‘Order‘) is not null drop table [Order]gocreate table [Order] (OId int not null, CusId int);goinsert into Customer values(1,‘小米‘),(2,‘大米‘),(3,‘mini‘)insert into [Order] values(1,1),(2,2),(3,NULL),(4,1)
--例如:需要统计每个顾客的订单量--使用count(*)select CID,count(*) from Customer left join [order] on Customer.CId=[order].CusId group by CId
实际情况CusId=3是没有订单的,数量应该是0,但是结果是1,count()里面的字段是左连接右边的表字段,如果你用的是主表字段结果页是错误的。
--正确的方法是使用count(CusId)select CID,count(CusId) from Customer left join [order] on Customer.CId=[order].CusId group by CId
3,子查询的表加上表别名
4,查询时使用*查询时一定不能使用”*”来代替字段来进行查询,无论你查询的字段有多少个,就算字段太多无法走索引也避免了解析”*”带来的额外消耗。
查询字段值列出想要的字段,避免出现多余的字段,字段越多查询开销越大而且可能会因为多列出了某个字段而引起查询不走索引。
5,使用存储过程的好处
- 减少网络通信量。调用一个行数不多的存储过程与直接调用SQL语句的网络通信量可能不会有很大的差别,可是如果存储过程包含上百行SQL语句,那么其性能绝对比一条一条的调用SQL语句要高得多。
- 执行速度更快。有两个原因:首先,在存储过程创建的时候,数据库已经对其进行了一次解析和优化。其次,存储过程一旦执行,在内存中就会保留一份这个存储过程缓存计划,这样下次再执行同样的存储过程时,可以从内存中直接调用。
- 更强的适应性:由于存储过程对数据库的访问是通过存储过程来进行的,因此数据库开发人员可以在不改动存储过程接口的情况下对数据库进行任何改动,而这些改动不会对应用程序造成影响。
- 布式工作:应用程序和数据库的编码工作可以分别独立进行,而不会相互压制。
- 更好的封装移植性。
- 安全性,它们可以防止某些类型的 SQL 插入攻击。
默认情况下,存储过程将返回过程中每个语句影响的行数。如果不需要在应用程序中使用该信息(大多数应用程序并不需要),请在存储过程中使用 SET NOCOUNT ON 语句以终止该行为。根据存储过程中包含的影响行的语句的数量,这将删除客户端和服务器之间的一个或多个往返过程。尽管这不是大问题,但它可以为高流量应用程序的性能产生负面影响。6,判断一条查询是否有值
IF NOT EXISTS/IF EXISTS 优于 COUNT(*)
7, 理解TRUNCATE和DELETE的区别
TRUNCATE操作没有记录删除日志操作
主要的原因是因为TRUNCATE操作不会激活触发器,因为TRUNCATE操作不会记录各行的日志删除操作,所以当你需要删除一张表的数据时你需要考虑是否应该如有记录日志删除操作,而不是根据个人的习惯来操作。
8,事务的理解
XACT_ABORT
---查询是否有打开事务SELECT XACT_STATE()DBCC OPENTRAN未查询到有打开事务当 SET XACT_ABORT 为 ON 时,如果执行 Transact-SQL 语句产生运行时错误,则整个事务将终止并回滚。当 SET XACT_ABORT 为 OFF 时,有时只回滚产生错误的 Transact-SQL 语句,而事务将继续进行处理。如果错误很严重,那么即使 SET XACT_ABORT 为 OFF,也可能回滚整个事务。OFF 是默认设置。编译错误(如语法错误)不受 SET XACT_ABORT 的影响。
9,条件字段的先后顺序
对于经常用作查询的字段放在第一个位置,其它的字段根据表的实际字段顺序排列,这样往往你的查询语句走索引的概率会更大。
10,避免使用长字节字段排序
order by Id 优于 order by CreateTime
database - 数据库设计/使用容易忽略的细节
标签:
小编还为您整理了以下内容,可能对您也有帮助:
数据库系统包括哪些内容?
数据库系统一般由4个部分组成:
(1)数据库(database,DB)是指长期存储在计算机内的,有组织,可共享的数据的集合。数据库中的数据按一定的数学模型组织、描述和存储,具有较小的冗余,较高的数据性和易扩展性,并可为各种用户共享。
(2)硬件:构成计算机系统的各种物理设备,包括存储所需的外部设备。硬件的配置应满足整个数据库系统的需要。
(3)软件:包括操作系统、数据库管理系统及应用程序。数据库管理系统(database management system,DBMS)是数据库系统的核心软件,是在操作系统的支持下工作,解决如何科学地组织和存储数据,如何高效获取和维护数据的系统软件。其主要功能包括:数据定义功能、数据操纵功能、数据库的运行管理和数据库的建立与维护。
(4)人员:主要有4类。第一类为系统分析员和数据库设计人员:系统分析员负责应用系统的需求分析和规范说明,他们和用户及数据库管理员一起确定系统的硬件配置,并参与数据库系统的概要设计。数据库设计人员负责数据库中数据的确定、数据库各级模式的设计。第二类为应用程序员,负责编写使用数据库的应用程序。这些应用程序可对数据进行检索、建立、删除或修改。第三类为最终用户,他们利用系统的接口或查询语言访问数据库。第四类用户是数据库管理员(data base administrator,DBA),负责数据库的总体信息控制。DBA的具体职责包括:具体数据库中的信息内容和结构,决定数据库的存储结构和存取策略,定义数据库的安全性要求和完整性约束条件,监控数据库的使用和运行,负责数据库的性能改进、数据库的重组和重构,以提高系统的性能
数据库设计包括两个方面的设计内容,它们是
数据库设计包括两个方面的设计内容:概念设计和逻辑设计。
数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。
数据库设计的设计内容包括:需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库的实施和数据库的运行和维护。
数据库设计(Database Design)是指根据用户的需求,在某一具体的数据库管理系统上,设计数据库的结构和建立数据库的过程。数据库系统需要操作系统的支持。
数据库设计是建立数据库及其应用系统的技术,是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性,为了支持相关程序运行,数据库设计就变得异常复杂,因此最佳设计不可能一蹴而就,而只能是一种“反复探寻,逐步求精”的过程,也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。
调查和分析用户的业务活动和数据的使用情况,弄清所用数据的种类、范围、数量以及它们在业务活动中交流的情况,确定用户对数据库系统的使用要求和各种约束条件等,形成用户需求规约。
需求分析是在用户调查的基础上,通过分析,逐步明确用户对系统的需求,包括数据需求和围绕这些数据的业务处理需求。在需求分析中,通过自顶向下,逐步分解的方法分析系统,分析的结果采用数据流程图(DFD)进行图形化的描述。
如何设计一个优秀的数据库
数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。 在数据库领域内,常常把使用数据库的各类系统统称为数据库数据库设计(database design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。 在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。 一、数据库和信息系统 (1)数据库是信息系统的核心和基础,把信息系统中大量的数据按一定的模型组织起来,提供存储、维护、检索数据的 功能,使信息系统可以方便、及时、准确地从数据库中获得所需的信息。 (2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。 (3)数据库设计是信息系统开发和建设的重要组成部分。 (4)数据库设计人员应该具备的技术和知识: 数据库的基本知识和数据库设计技术 计算机科学的基础知识和程序设计的方法和技巧 软件工程的原理和方法 应用领域的知识 二、数据库设计的特点 数据库建设是硬件、软件和干件的结合 三分技术,七分管理,十二分基础数据 技术与管理的界面称之为“干件” 数据库设计应该与应用系统设计相结合 结构(数据)设计:设计数据库框架或数据库结构 行为(处理)设计:设计应用程序、事务处理等 结构和行为分离的设计 传统的软件工程忽视对应用中数据语义的分析和抽象,只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究,忽视了对行为的设计 如图: 三、数据库设计方法简述 手工试凑法 设计质量与设计人员的经验和水平有直接关系 缺乏科学理论和工程方法的支持,工程的质量难以保证 数据库运行一段时间后常常又不同程度地发现各种问题,增加了维护代价 规范设计法 手工设计方 基本思想 过程迭代和逐步求精 规范设计法(续) 典型方法: (1)新奥尔良(new orleans)方法:将数据库设计分为四个阶段 s.b.yao方法:将数据库设计分为五个步骤 i.r.palmer方法:把数据库设计当成一步接一步的过程 (2)计算机辅助设计 oracle designer 2000 sybase powerdesigner 四、数据库设计的基本步骤 数据库设计的过程(六个阶段) 1.需求分析阶段 准确了解与分析用户需求(包括数据与处理) 是整个设计过程的基础,是最困难、最耗费时间的一步 2.概念结构设计阶段 是整个数据库设计的关键 通过对用户需求进行综合、归纳与抽象,形成一个于具体dbms的概念模型 3.逻辑结构设计阶段 将概念结构转换为某个dbms所支持的数据模型 对其进行优化 4.数据库物理设计阶段 为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法) 5.数据库实施阶段 运用dbms提供的数据语言、工具及宿主语言,根据逻辑设计和物理设计的结果 建立数据库,编制与调试应用程序,组织数据入库,并进行试运行 6.数据库运行和维护阶段 数据库应用系统经过试运行后即可投入正式运行。 在数据库系统运行过程中必须不断地对其进行评价、调整与修改 设计特点: 在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行,相互参照,相互补充,以完善两方面的设计 设计过程各个阶段的设计描述: 如图: 五、数据库各级模式的形成过程 1.需求分析阶段:综合各个用户的应用需求 2.概念设计阶段:形成于机器特点,于各个dbms产品的概念模式(e-r图) 3.逻辑设计阶段:首先将e-r图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式;然后根据用户处理的要求、安全性的考虑,在基本表的基础上再建立必要的视图(view),形成数据的外模式 4.物理设计阶段:根据dbms特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式 六、数据库设计技巧 1. 设计数据库之前(需求分析阶段) 1) 理解客户需求,询问用户如何看待未来需求变化。让客户解释其需求,而且随着开发的继续,还要经常询问客户保证其需求仍然在开发的目的之中。 2) 了解企业业务可以在以后的开发阶段节约大量的时间。 3) 重视输入输出。 在定义数据库表和字段需求(输入)时,首先应检查现有的或者已经设计出的报表、查询和视图(输出)以决定为了支持这些输出哪些是必要的表和字段。 举例:假如客户需要一个报表按照邮政编码排序、分段和求和,你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。 4) 创建数据字典和er 图表 er 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。er图对表明表之间关系很有用,而数据字典则说明了每个字段的用途以及任何可能存在的别名。对sql 表达式的文档化来说这是完全必要的。 5) 定义标准的对象命名规范 数据库各种对象的命名必须规范。 2. 表和字段的设计(数据库逻辑设计) 表设计原则 1) 标准化和规范化 数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式,但third normal form(3nf)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说,遵守3nf 标准的数据库的表设计原则是:“one fact in one place”即某个表只包括其本身基本的属性,当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点:有一组表专门存放通过键连接起来的关联数据。 举例:某个存放客户及其有关定单的3nf 数据库就可能有两个表:customer 和order。order 表不包含定单关联客户的任何信息,但表内会存放一个键值,该键指向customer 表里包含该客户信息的那一行。 事实上,为了效率的缘故,对表不进行标准化有时也是必要的。 2) 数据驱动 采用数据驱动而非硬编码的方式,许多策略变更和维护都会方便得多,大大增强系统的灵活性和扩展性。 举例,假如用户界面要访问外部数据源(文件、xml 文档、其他数据库等),不妨把相应的连接和路径信息存储在用户界面支持表里。还有,如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等),那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上,如果过程是数据驱动的,你就可以把相当大的责任推给用户,由用户来维护自己的工作流过程。 3) 考虑各种变化 在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。 举例,姓氏就是如此(注意是西方人的姓氏,比如女性结婚后从夫姓等)。所以,在建立系统存储客户信息时,在单独的一个数据表里存储姓氏字段,而且还附加起始日和终止日等字段,这样就可以跟踪这一数据条目的变化。 字段设计原则 4) 每个表中都应该添加的3 个有用的字段 drecordcreationdate,在vb 下默认是now(),而在sql server ? 下默认为getdate() srecordcreator,在sql server 下默认为not null default ? user nrecordversion,记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因 ? 5) 对地址和电话采用多个字段 描述街道地址就短短一行记录是不够的。address_line1、address_line2 和address_line3 可以提供更大的灵活性。还有,电话号码和邮件地址最好拥有自己的数据表,其间具有自身的类型和标记类别。 6) 使用角色实体定义属于某类别的列 在需要对属于特定类别或者具有特定角色的事物做定义时,可以用角色实体来创建特定的时间关联关系,从而可以实现自我文档化。 举例:用person 实体和person_type 实体来描述人员。比方说,当john smith, engineer 提升为john smith, director 乃至最后爬到john smith, cio 的高位,而所有你要做的不过是改变两个表person 和person_type 之间关系的键值,同时增加一个日期/时间字段来知道变化是何时发生的。这样,你的person_type 表就包含了所有person 的可能类型,比如associate、engineer、director、cio 或者ceo 等。还有个替代办法就是改变person 记录来反映新头衔的变化,不过这样一来在时间上无法跟踪个人所处位置的具体时间。 7) 选择数字类型和文本类型尽量充足 在sql 中使用smallint 和tinyint 类型要特别小心。比如,假如想看看月销售总额,总额字段类型是smallint,那么,如果总额超过了$32,767 就不能进行计算操作了。 而id 类型的文本字段,比如客户id 或定单号等等都应该设置得比一般想象更大。假设客户id 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。 8) 增加删除标记字段 在表中包含一个“删除标记”字段,这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。 3. 选择键和索引(数据库逻辑设计) 键选择原则: 1) 键设计4 原则 为关联字段创建外键。 ? 所有的键都必须唯一。 ? 避免使用复合键。 ? 外键总是关联唯一的键字段。 ? 2) 使用系统生成的主键 设计数据库的时候采用系统生成的键作为主键,那么实际控制了数据库的索引完整性。这样,数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点:当拥有一致的键结构时,找到逻辑缺陷很容易。 3) 不要用用户的键(不让主键具有可更新性) 在确定采用什么字段作为表的键的时候,可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。 4) 可选键有时可做主键 把可选键进一步用做主键,可以拥有建立强大索引的能力。 索引使用原则: 索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。 1) 逻辑主键使用唯一的成组索引,对系统键(作为存储过程)采用唯一的非成组索引,对任何外键列采用非成组索引。考虑数据库的空间有多大,表如何进行访问,还有这些访问是否主要用作读写。 2) 大多数数据库都索引自动创建的主键字段,但是可别忘了索引外键,它们也是经常使用的键,比如运行查询显示主表和所有关联表的某条记录就用得上。 3) 不要索引memo/note 字段,不要索引大型字段(有很多字符),这样作会让索引占用太多的存储空间。 4) 不要索引常用的小型表 不要为小型数据表设置任何键,假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。 4. 数据完整性设计(数据库逻辑设计) 1) 完整性实现机制: 实体完整性:主键 参照完整性: 父表中删除数据:级联删除;受限删除;置空值 父表中插入数据:受限插入;递归插入 父表中更新数据:级联更新;受限更新;置空值 dbms对参照完整性可以有两种方法实现:外键实现机制(约束规则)和触发器实现机制 用户定义完整性: not null;check;触发器 2) 用约束而非商务规则强制数据完整性 采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键)的完整性所以不能强加于其他完整性规则之上。 3) 强制指示完整性 在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。 4) 使用查找控制数据完整性 控制数据完整性的最佳方式就是用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找:国家代码、状态代码等。 5) 采用视图 为了在数据库和应用程序代码之间提供另一层抽象,可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。 5. 其他设计技巧 1) 避免使用触发器 触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器,你最好集中对它文档化。 2) 使用常用英语(或者其他任何语言)而不要使用编码 在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码,可以在编码旁附上用户知道的英语。 3) 保存常用信息 让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库,当客户抱怨他们的数据库没有达到希望的要求而与你联系时,这样做对非客户机/服务器环境特别有用。 4) 包含版本机制 在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长,用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。 5) 编制文档 对所有的快捷方式、命名规范、和函数都要编制文档。 采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。 对数据库文档化,或者在数据库自身的内部或者单独建立文档。这样,当过了一年多时间后再回过头来做第2 个版本,犯错的机会将大大减少。 6) 测试、测试、反复测试 建立或者修订数据库之后,必须用用户新输入的数据测试数据字段。最重要的是,让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。 7) 检查设计 在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说,针对每一种最终表达数据的原型应用,保证你检查了数据模型并且查看如何取出数据。