数据库设计和使用的一些常用好习惯

好的习惯,需要不断的培养和强化,直到成为一种习惯,然后成为思想的一部分。

上班前或者下班后,有空我都要给我家小家伙读一读《三字经》或者《弟子规》,他可能并不懂这些文字的内容,但是我希望这些知识能够陪伴他长大,成为思想和行动的一部分。

我们设计系统架构、做数据库规划的时候,也有一些基本的原则。

不知道没有关系,多学习就知道了

不懂没有关系,多看几次就懂了

持之以恒就是人生。

数据库常用的好习惯记录下来,没事就翻翻。

设计表和索引等

1.   选择合适的小字段,可以减少数据库行数据的大小,并提高索引匹配的效率,进而提升数据库性能。如日期采用date代替datetime、类型或标记使用tinyint代替smallint和int、使用定长字段代替非定长字段(如char代替varchar2),都能或多或少减少数据行大小,提高数据库缓冲池的命中率;

2.   主键,其选型更会对表索引的稳定和效率带来很大的影响,一般建议考虑数据库自增或自主维护的唯一数值。

3.   适当的冗余一些数据,这样在设计表的时候虽然不舒服,但是可以提高很多性能;

4.   如果业务内容比较多,不要把所有字段都放到一个表中,这样表空间会很大,查询速度会很慢,要明确“哪些字段常用,哪些字段不常用”,尽量把不常用的字段放在附表里面,与主表一对一关联。

5.   在高分离度字段创建索引,比如用户表中的电话号码字段,索引的效率会非常高;

6.   类型,状态等内容基本变化不多的字段,原则上用位图索引比普通索引有效些,但是创建使用位图索引,必须要验证效率是否得到提升;

7.  不要太依赖于建索引,一般而言,创建索引会提升相应的查询速度,但是索引太多,会影响输入的写入。

使用表的一些习惯

1.  正如我们编写JAVA程序,可以多利用Apache Commons工具包一样,多利用Oracle自带的内部函数不仅可以提升开发效率,也能提高Sql语句执行效率;

2.  尽量把sql语句写成 dm=? ,然后再赋值,而不是直接dm=9,这样oracle每次执行都要编译这条语句,而前面的那种方法,oracle只编译一次。

3.  Exists比in 的效率大多数时候都会高,具体在选择IN或EXIST操作时,要根据主子表数据量大小来具体考虑。

3.

4.  Not in最好在代码中不要出现,效率不高,如果一定要用,可以用 minus 或则not exists代替。

4.

5.  where条件中,尽量不要用to_char,to_date,upper等方法进行格式转换。转换和计算操作尽量放=右边,如果在左边进行了转换,那么会进行全表扫描;如果索引不是基于函数的,那么当在Where子句中对索引列使用函数时,索引不再起作用。

6.  不要把很复杂的逻辑用一条语句来实现,如果这种复杂的语句执行效果不理想,可以尝试把它拆开成简单的语句,看看效率是否提升。

7.  尽量不要用“<>”或者“!=”操作符。对不等于操作符的处理会造成全表扫描,可以用“<” or “>”代替。例如:a<>0改为 a>0 or a<0,a<>’’ 改为 a>’ ’,用“>=”替代“>”。

8.  Where子句中出现IS NULL或者IS NOT NULL时,Oracle会停止使用索引而执行全表扫描。可以考虑在设计表时,对索引列设置为NOTNULL。这样就可以用其他操作来取代判断NULL的操作。

8.

9.  当通配符“%”或者“_”作为查询字符串的第一个字符时,索引不会被使用,因此一般不要作为第一个字符出现。或者尽可能不用这种方式;

10.  对于有连接的列“||”,最后一个连接列索引会无效。尽量避免连接,可以分开连接或者使用不作用在列上的函数替代。

10.

11.  对数据类型不同的列进行比较时,会使索引失效。

12.  UNION操作符会对结果进行筛选,消除重复,数据量大的情况下可能会引起磁盘排序。如果不需要删除重复记录,应该使用UNION ALL。

12.

13.  Oracle从下到上处理Where子句中多个查询条件,所以表连接语句应写在其他Where条件前,可以过滤掉最大数量记录的条件必须写在Where子句的末尾。Oracle从右到左处理From子句中的表名,所以在From子句中包含多个表的情况下,将记录最少的表放在最后。Oracle10g以及以上的版本,以及对这个问题就进行了优化,但是这个习惯还是不错的,值得保留。

14.  OrderBy语句中的非索引列会降低性能,可以通过添加索引的方式处理。如果排序的数据量比较大,对性能的影响非常大,尽量避免使用。唯一性索引是一个比较好的折中方法;

时间: 2024-12-09 11:39:28

数据库设计和使用的一些常用好习惯的相关文章

数据库设计中的14个常用技巧

1. 原始单据与实体之间的关系 可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体. 在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体. 这里的实体可以理解为基本表.明确这种对应关系后,对我们设计录入界面大有好处. [例1]:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表.社会关系表.工作简历表.   这就是"一张原始单证对应多个实体"的典型例子. 2.

MySql三大范式与数据库设计和表创建常用语句

[数据库设计的三大范式] 1.第一范式(1NF First Normal Fromate):数据表中的每一列(字段),必须是不可拆分的最小单元.也就是确保每一列的原子性. 例如: userInfo: '山东省烟台市 13181621008' => userAds:'山东省烟台市' tel:'13181621008' 2.第二范式(2NF):满足1NF后,要求:表中所有的列,都必须功能依赖于主键,而不能有任何一列与主键没有关系.(一张表值描述一件事情) 3.第三范式(3NF):满足2NF后,要求:

[转]数据库设计中的常用技巧

本文介绍了数据库设计中的14个技巧,这是许多人在大量的数据库分析与设计实践中,逐步总结出来的-- 下述十四个技巧,是许多人在大量的数据库分析与设计实践中,逐步总结出来的.对于这些经验的运用,读者不能生帮硬套,死记硬背,而要消化理解,实事求是,灵活掌握.并逐步做到:在应用中发展,在发展中应用. 1. 原始单据与实体之间的关系 可以是一对一.一对多.多对多的关系.在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体.在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个

DBA词典:数据库设计常用词汇中英文对照表

1. Access method(访问方法):此步骤包括从文件中存储和检索记录. 2. Alias(别名):某属性的另一个名字.在SQL中,可以用别名替换表名. 3. Alternate keys(备用键,ER/关系模型):在实体/表中没有被选为主健的候选键. 4. Anomalies(异常)参见更新异常(update anomalies) 5. Application design(应用程序设计):数据库应用程序生命周期的一个阶段,包括设计用户界面以及使用和处理数据库的应用程序. 6. Att

mysq数据库设计(主键与外键)

主键可以是真实实体的属性,但是常用的好的解决方案是,利用一个与实体信息不相关的属性,作为唯一标示(加个id字段)主键与业务逻辑不发生关系,只用来标示记录 可以在定义完字段后,再定义多列主键(组合主键) 例:primary key(id,name,age);(不是说3个字段都是主键,因为一个表只能有一个主键,可以是3个字段组合成的主键) 设计: 两个实体表内,存在相同的主键字段 如果记录的主键值等于另一个关系表内记录的主键则两天记录对应 1:1对应  数据库设计的时候(常用的信息和不常用的信息分开

数据库设计二《函数依赖和三范式》

函数依赖: 定义:R(U)是在属性集U上的关系模式,X,Y是U的子集.若对于R(U)的任意一个可能关系r,r中的不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则称X函数确定Y,或者Y函数依赖X,记作X--->Y. 单纯的概念有点难以理解,通过例子1:属性集U,关系模式R(U),子集X,Y,可能关系r1. 可以理解为X能唯一确定Y,则X--->Y.常用为主键------>其他属性 函数依赖和三范式 函数依赖的分类:完全依赖,部分依赖,传递依赖. 完全依赖和一范式 完全依赖:X

5-2数据库设计

5-2数据库设计 tags:数据库 基本步骤 步骤: 1. 需求分析阶段 进行数据库设计首先必须准确了解与分析用户需求.需求分析是整个设计过程的基础,是最困难和最耗费时间的一步. 2. 概念结构设计阶段 概念设计是整个数据库设计的关键,它通过对用户需求进行综合.归纳与抽象,行程一个独立于具体数据库管理系统的概念模型. 在概念结构设计阶段行程独立于机器特点,独立于各个关系数据库管理系统产品的概念模式,一般用ER图表示 3. 逻辑结构设计阶段 逻辑结构设计是将概念结构转为某个数据库管理系统所支持的数

数据库设计的几个建议

本文导读:数据库设计是信息系统设计的基础,一个好的数据库设计在满足了软件需求之外,还要易维护.易扩充等等要求,还要考虑到数据的一致性.冗余性.访问效率,数据库设计包括:库的设计,表的设计,字段的设计,主键和外键的设计,索引设计,约束设计等等,下面介绍数据库设计的几个建议 一.一般好的数据库设计需要注意以下几点 1.一个好的数据库设计首先要满足用户的需求 所有信息系统最后都将提交给最终用户使用,对于这一点,相信大家都已经达成共识.但是准确地把握用户的需求是很难的,虽然各方面的专家已经从不同方面给出

写给开发者看的关系型数据库设计

目录 一 Codd的RDBMS12法则——RDBMS的起源 二 关系型数据库设计阶段 三 设计原则 四 命名规则 数据库设计,一个软件项目成功的基石.很多从业人员都认为,数据库设计其实不那么重要.现实中的情景也相当雷同,开发人员的数量是数据库设计人员的数倍.多数人使用数据库中的一部分,所以也会把数据库设计想的如此简单.其实不然,数据库设计也是门学问. 从笔者的经历看来,笔者更赞成在项目早期由开发者进行数据库设计(后期调优需要DBA).根据笔者的项目经验,一个精通OOP和ORM的开发者,设计的数据