-
关于数据库字段命名与实体类命名选择驼峰还是下划线
2018-09-20 14:39:27因为数据库字段、索引对大小写是不敏感的,驼峰标识无意义; 所以一般采用数据库字段下划线, 实体类驼峰的命名方式因为数据库字段、索引对大小写是不敏感的,驼峰标识无意义;
所以一般采用数据库字段下划线, 实体类驼峰的命名方式 -
关于数据库命名规范
2012-05-09 10:18:562. 数据库对象命名规范 数据库对象={表,视图(查询),索引,关联,存储过程(参数查询),函数} 规则:对象名字由前缀和实际名字组成,他们之间加下划线,不要在对象名的字符之间留空格,长度不超过30字符。 [对象...0. 字符集合
a-z A-Z 0-9 和 _ 共 63个
1. 所有字条以小写字母开头,所有名词采用单数,所以前缀都要小写
如:userIduser_id
2. 数据库对象命名规范
数据库对象={表,视图(查询),索引,关联,存储过程(参数查询),函数}
规则:对象名字由前缀和实际名字组成,他们之间加下划线,不要在对象名的字符之间留空格,长度不超过30字符。
[对象名字]=[前缀]_[实际名字]
前缀:使用小写字母
表 tb
视图 vi
索引 idx
关联 rl
存储过程 sp
函数 fn
实际名字:实际名字尽量描述实体的内容,由单词或单词组合,每个单词(第一个除外)的首字母大写,其他字母小写,不以数字和_开头,单词与单词间不用下划线。
[实际名字]=[小写字母开头的单词][大写字母开头的单词]...[大写字母开头的单词
例如:userNamepassWord userRegisterTime
[单词]=[a-z|A-Z][a-z|A-Z|0-9|_]...[a-z|A-Z|0-9|_]
例子:tb_webUservi_userOrder
3. 数据库表命名规范
表名由 前缀(tb) 接 _ 接 实际名字组成
[表名]=tb_[实际名字]
4. 字段命名规范
[字段名]=[表名简称]_[实际名字]
现在约定,[表名简称]=[表名]的[实际名字]部分 的各个单词首字母安顺序组合
如:tb_userInfomation应用此规则,其表名简称为uI
5. 视图命名规范
[视图]=vi_[实际名字]
6. 存储过程命名规范
[存储过程名]=sp_[实际名字]_[操作名字]
[操作名字]=[insert|delete|update|calculate|confirm]
例如:sp_userState_update
7. 索引命名规范
[索引]=idx[0-9]_[表名简写]_[实际名字]
例子:idx0_uInfo_age
注:[表名简写]不同于上面的[表名简称],它采用下面的字串简化规则。参见最后9。
8. 关联命名规范
[关联]=rl_[表名简写]_[表名简写]
例子:rl_uInfo_msg
8.数据库设计文档规范
表名: tb_userInformation
作者: XXX
日期: 2004-12-17
版本: 1.0
描述: 保存用户资料
具体内容:(以表格形式)
-
Oracle数据库索引
2010-07-02 13:27:00Oracle数据库索引如果你在数据库方面是一个新手,又或者你对Oracle数据库不是很熟悉,那你可能会发现关于索引和构建索引策略方面的讨论资料看起来很艰涩。不过,只要你对于能满足数据库管理员日常管理相关的选项稍加...Oracle数据库索引如果你在数据库方面是一个新手,又或者你对Oracle数据库不是很熟悉,那你可能会发现关于索引和构建索引策略方面的讨论资料看起来很艰涩。不过,只要你对于能满足数据库管理员日常管理相关的选项稍加注意,其实要入手还是很容易的。
1)b-tree索引
Oracle数据库中最常见的索引类型是b-tree索引,也就是B-树索引,以其同名的计算科学结构命名。每当你发布基本的没有经过进一步修改的CREATE INDEX语句时,就是在创建b-tree索引。这里不打算对b-tree索引进行更多深入的探讨,这些用户都可以自己了解。基本上这些索引存储你创建的索引所在的列值以及用来查找自身行的指向实际数据表的指针。记住,这也就意味着要进行多路查询,其中一个查询各个节点和索引的叶节点,然后才是表的行自身。这就是为什么Oracle的优化器在某种情况下会选择执行全表扫描而不执行索引查找的原因了,因为全表扫描执行起来实际上可能会更快一些。还要注意的是,如果你的索引是创建在多个列上的话,那么第一列(leading column)非常重要。假设你有一个多列索引(也称为级联索引),索引列的排列顺序是c列到d列,你可以对使用该索引c列单独进行一次查询,但你不能使用该索引对d列冶金行一次单独的查询。
2)基于函数的索引
如果在搜索时你读取很多行,或者你的索引选择性不大,又或者你在级联索引中使用了第一列以外的列,Oracle数据库有时候会选择不使用索引。那么如果你想要执行一个大小写不敏感的搜索呢?像下面的指令:WHERE UPPER(first_name) = 'JOHN'。
这也不会使用first_name字段上的索引。为什么?因为Oracle不得不将UPPER函数用在该索引所有(ALL)的值上,所以还不如做一次全表扫描。所以,很多时候Oracle创建基于函数的索引就是为了这个目的。
3)反转关键字索引
你还可以看到这些反转关键字索引,而且不时还要用到这些索引。假设有一列包含了“餐厅甲”、“餐厅乙”、“餐厅丙”等类似名字。可能这不是一个很好的例子,不过关键的一点是拥有很多唯一值,但其关键字的前面一部分变化不大。因为Oracle会在将REVERSE关键字指定给b-tree前把REVERSE字符串简化,所以使用反转关键字索引可能是最好的。这样的一个索引可能更平衡、有用,搜索起来更快。
更多外部索引类型
Oracle还提供了很多更为复杂的索引类型。不过请注意,你最好全面阅读过相关的说明文档后再使用这些索引,因为它们各自都有各自特定的适用范围。
1)位图索引(bitmap index)
假设数据库表中有一列其选择性非常窄,例如性别列,该用什么类型的索引?你可能会考虑对其使用位图索引。因为位图索引正是为相异值很少的列而创建的。但需要考虑的因素还不只这些。一般而言,只有当你对表中值相宜度较小的多个不同的列都使用位图索引,这样位图索引才有用,因为你可以一起使用这些索引才能对列产生更大的选择性,否则你还是需要对这些列进行一次全表扫描。例如,对于性别列,其索引只能有两个唯一值,那么用这个索引对表的任何搜索有可能都返回一半的记录。其次,这些索引是为数据仓库而设计的,所以其假定条件是数据不会发生很大的改变。这些索引不能用来满足事务数据库或更新频繁的数据库。应该说,对位图索引的表进行更新根本没有一点效率。
2)位图连接索引(bitmap join index)
位图连接索引比位图索引更进了一步。这些索引将位图化的列完全从表数据中抽取出来,并将其存储在索引中。其假定条件是这些列集合必须一起查询。同样的,这也是为数据仓库数据库而设计的。除了在句法最后有一个WHERE子句之外,位图连接索引的创建指令就像创建位图索引的CREATE BITMAP INDEX一样。
3)压缩索引
压缩索引实际是标准b-tree索引的一个选项。压缩索引的叶节点更少,所以总的I/O数量和需要的缓存也更少。这些都意味着Oracle的优化器更可能使用这些压缩索引,而不倾向于使用标准的非压缩索引。不过,这些好处也是有代价的,当你对这些压缩索引进行存取操作时,要消耗更多的CPU来进行解压缩。而且,当你阅读关于优化器如何使用这些索引,又是如何选择合适的压缩级别的资料时,就开始变得晦涩了。不同的用户不同的设置从压缩索引中得到的好处也可能会有所不同。
4)降序索引(descending index)
这是基于函数索引的一种特殊类型。降序索引可以显著优化ORDER BY x, y, z DESC子句查询的。
5)分区索引(partitioned index)
如果你的数据库中有一个分区表,你就有机会体验几种新的索引类型,从贯穿所有分区的全局分区索引(global)和集中于各个单独分区的本地分区索引(local)。这里不再进行赘述,想知道细节问题可以查询相关文献。
6)索引组织表(index organized table,IOT)
这是在Oracle 9i中引进的一种新类型表。Oracle会将级联索引及其扩展类型的索引用于表中所有的列。当所有数据都载入到索引结构之后,表就成多余的了,你尽可以将表本身删除掉。这就是索引组织表。
7)簇索引(cluster index)
基本上,簇索引就是将多个表的相同列放在一起,而对该列使用用一个簇索引。这种索引在实际应用中比较少,因为还有各种有待解决的性能问题存在。
8)域索引(domain index)
当我们创建为用户自定义数据类型(datatype)创建用户自定义索引类型(indextype)时就要使用域索引。
9)隐藏索引(invisible index)
这是Oracle 11g中推出的新特性。其创建过程和标准索引一样,但创建后对于基于代价的优化器(CBO)是不可见的。这可以让你对性能进行大型测试查询,而不会影响现有的正在运行的应用程序。
10)虚拟索引(virtual index)
这是为测试人员和开发人员准备的又一个工具。虚拟索引(不分配段空间)可以让你在不需要实际创建索引的情况下,测试新索引及其对查询计划的影响。对于GB级的表来说,构建索引非常耗费资源而且还要占用大量时间。
11)其他的索引类型
Oracle数据库还提供了很多其他类型的索引,例如用来为字符型大型二进制对象(CLOB)或其他大型文本数据构建索引的Oracle TEXT,Oracle Spatial等。有兴趣的读者可以自己查找相关资料了解。
都是为了优化器
如果你曾经广泛接触过MySQL和其他的数据库,你会发现甲骨文虽然是全球领先的数据库供应商,但它们的数据库对于用户来说用起来其实并不是很方便。提到优化器这个问题可能有点离题了,不过Oracle数据库最基本的食料就是优化器了,这的确是种挺特别的调料,而且变得越来越美味了。市面上有很多以Oracle基于代价的优化器(Cost Based Optimizer,CBO)为主题内容的书籍,专门介绍分析表和索引的技巧和策略。
对于数据库,除了需要一直更新你的统计信息之外,你可能还需要不断测试新的查询。使用解析计划机制,并进行优化以便减少总I/O量以及排序和合并数据的计算量,只有这样你才能获得更好的性能表现。
总结
虽然Oracle数据库的索引世界有点吓人,不过实际上你平常经常使用的索引就只有那么一些。而且,不管唱反调的人怎样诋毁,Oracle的优化器都已经设计相当出色;总体而言,Oracle很擅长于让你的数据库运行地更有效率。虽然这并不意味着你不需要对自己的SQL进行调优,不过,如果你一直保持着最新的统计信息,并让Oracle为你整理出你所需要的最小数据集的话,它能够以极快的速度满足你的需要。 -
Mysql优化小议(数据库设计、命名规范、索引优化、mysql面试、java面试)
2019-04-16 10:25:31本篇内容是在公司内部培训的一次内容,主要涉及到数据库的设计和SQL优化,及索引的一些概念,今天分享出来,希望能够对需要的朋友起到帮助,如果内容有错误,也请留言指出,感激不尽,转载请注明出处。 另外以后我...写在最前面,本篇内容是在公司内部培训的一次内容,今天分享出来,希望能够对需要的朋友起到帮助,如果内容有错误,也请留言指出,感激不尽,转载请注明出处。
另外以后我会整理一个关于Mysql知识点的系列文章,感兴趣的朋友可以扫描下面的二维码加群。
------------ 废话不多说,开始正文 -----------------一、数据库设计
-
三范式简单理解
– 第一范式(1NF):字段具有原子性,不能再分(所有关系型数据库系统都满足第一范式)
– 第二范式(2NF):一个表必须有主键,即每行数据都能被唯一的区分
– 第三范式(3NF):一个表中不能包涵其他相关表中非关键字段的信息,即数据表不能有沉余字段注:为了使用方便,很难完全符合 第三范式,适当冗余是需要的
-
MySql 存储引擎(InnoDB, MyISAM)
– MyISAM:不支持事物, 写入和读取速度比较快,适合写少,读多的场景
– InnoDB:支持事物,行锁 -
命名
– 表 名:下划线连接全小写单词,例:product,product_order -
字段名:
– 所有字段都不允许为NULL(特殊考虑:date、datetime)
– 默认值:应考虑哪些字段不应允许有默认值
– 小写驼峰,其中:- bool型:is* 或 allow*,如isDisabled(是否禁用)或allowClose(允许关闭)
- datetime类型:*Time,如startedTime
- date类型(YYYY-MM-DD):*Date,如endDate
– 关联字段名为对应AR类名首字母小写+关联字段名,如:user_id,order_id
-
主键:建议使用非业务字段做主键(id,int 自增)
-
外键:不使用外键(由程序保证约束)
注:要控制表的字段数量,根据业务规则适当的分表
二、SQL执行顺序=
- FROM:对FROM子句中前两个表执行笛卡尔积生成虚拟表vt1
- ON:对vt1表应用ON筛选器只有满足< join_condition> 为真的行才被插入vt2
- 如果 FROM 包含两个以上表则对上一个联结生成的结果表和下一个表重复执行步骤1 和 步骤2
- WHERE:对vt2应用 WHERE 筛选器只有使< where_condition> 为true的行才被插入vt3
- GROUP BY:按GROUP BY子句中的列对vt3中的行分组生成vt4
- HAVING:对vt4应用HAVING筛选器只有使< having_condition> 为true的组才插入vt5
- SELECT:处理select列表产生vt6
- DISTINCT:将重复的行从vt6中去除产生vt7
- ORDER BY:将vt7的行按order by子句中的列列表排序生成一个游标vc8
- LIMIT:从vc8的开始处选择指定数量或比例的行生成vt9 并返回调用者
参考: https://www.cnblogs.com/annsshadow/p/5037667.html
三、索引
类型:
- 主键索引:primary,数据的物理存储顺序
- 唯一索引:unique index
- 普通索引:index
- 复合索引:最左前缀原则
选择索引的数据字段:
- 越小的数据类型通常更好
- 简单的数据类型更好
- 尽量避免NULL
无法使用索引的情况:
-
以%开头的like查询
例如: explain select * from order where number like '%201703'
-
数据类型出现隐式转换的时候也不会使用索引
例如:explain select * from order where number = 20170328104740498530
-
复合索引的情况下,不满足最左前缀原则,则不会使用索引
例如:explain select a.* from order as a where a.uid = 1 and a.status = 2
-
用 or 分割开的条件,如果 or 前的条件中的列有索引,而后面的列中没有索引,那么涉及的索引都不会被用到
例如:explain select a.* from order as a where a.uid = 1 or a.status=2
-
字段进行运算、或格式转化后,将无法使用索引
例如:explain select a.* from order as a where from_unixtime(a.create_time, '%Y%m%d') = '20170101'
-
!= 、 not in 无法使用索引
例如:explain select * from order where create_time not in (13423424232)
-
查询条件使用了索引,就一定会用到吗?
如果mysql估计使用索引扫描比全表扫描更慢,则不使用索引。(扫描数据超过30%,都会走全表)
参考:
https://dev.mysql.com/doc/refman/5.5/en/optimization-indexes.html
https://www.cnblogs.com/tgycoder/p/5410057.html四、SQL语句建议
-
书写SQL时要注意缩进
select from table1 as t1 inner join table2 as t2 on t1.col1 = t2.cols where group by having order by limit
-
INSERT:格式 NSERT INTO TABLE1(col1, col2) VALUES (‘yayun’,23)
-
大量数据写入,一定要使用批量的方式:INSERT INTO TABLE1(col1, col2) VALUES (‘yayun’,23),(‘tom’,26),(‘atlas’,32),(‘david’,25)…
-
避免使用 SELECT * 语句, 只返回需要的数据字段
-
当在SQL语句中连接多个表时, 为每个表都起别名
Select A.ID, A.col1, B.col2 from table1 A inner join table2 B on A.ID=B.ID where 。。。
-
合理写WHERE子句,不要写没有 WHERE 条件的 SQL 语句
-
杜绝不必要的子查询和连接表,多余排序
select count(*) from userinfo as a left join user as b on a.id = b.uid #这个连接真的需要吗? left join user_bank as c on a.id = c.uid #一个还不够,又来一个? where uid in (7704,11027,.....) order by a.reg_time desc #这个排序有用吗?
-
合并对同一表同一条件的多次 UPDATE
update tablename set col1 = '1111' where id = 1 update tablename set col2 = '2222' where id = 1 这两个语句应该合并成以下一个语句 update tablename set col1 = '1111', col2 = '2222' where id = 1
-
避免 IN 子句,当子句中有多个值且表数据较多时,速度下降明显,可以采用表关联查询来代替
-
OR 改写为 IN (OR 的效率更低)
-
使用 union all 替代 union (union有去重开销)
-
能使用 inner join 就不使用 left join(思考:left join 后的 on 条件 和 where 条件 的区别)
-
exists、not exists 当子查询的表很大时,性能很差,可改为 left join 或 inner join
-
SQL语句尽可能简单,复杂查询可以借助临时表或内存表
-
简单的事务,事物会锁表/行,尽可能的让事物快速执行完成
-
参数的传递:SQL 语句的编写,变量不要直接拼接到语句中,
结论:
- 尽量少的查询数据
- 使用子查询时,确保子查询数据量要小
- 合理使用索引
五、explain及其输出
作用:
- 显示mysql如何使用索引来处理select语句以及连接表
EXPLAIN 列的解释:
-
id:执行序号,数字大的先执行,数字相同,从上到下执行
-
select_type:查询的类型,主要是区别普通查询和联合查询、子查询之类的复杂查询
– SIMPLE:简单查询,没有使用 UNION、子查询等例如:explain select * from user where id = 1
– PRIMARY:在嵌套的查询中是最外层的SELECT语句,在UNION查询中是最前面的SELECT语句
– SUBQUERY:子查询中的第一个 SELECT
例如: explain select o.number from order as o where o.uid = ( select a.id from user as a where a.id = 1 )
– DEPENDENT SUBQUERY:子查询中的第一个 SELECT, 并且依赖外部查询
– UNION: 使用了 UNION 的第二个 select
– DEPENDENT UNION:使用了 UNION 的第二个 select,并且依赖外部查询
– UNION RESULT:UNION 结果例如:explain select o.number from order as o where uid in ( select a.id from user as a where a.id in (1,10,20) union select b.id from user as b where b.id in (11,21,31) ) 上面的写法会优化成下面这样执行 explain select o.number from order o where exists ( select a.id from user as a where a.id in (1,10,20) and a.id = o.uid union select b.id from user as b where b.id in (11,21,31) and b.id = o.uid );
– DERIVED:派生表,该临时表是从子查询派生出来的,位于FROM中的子查询
例如:explain select b.number from (select * from order as a) as b
-
table:查询的表
– <unionM,N>:UNION 查询结果
– < derivedN>: 派生表,FROM 子查询结果 -
type:访问类型
– system:这是const连接类型的一种特例,表中只有一行数据
– const:表示只有一行匹配,只读取一次,查询前读取,当查询条件是主键或唯一索引字段时(高效)例如:explain SELECT * FROM `user` WHERE id = 501
– eq_ref:唯一性索引扫描,对于每个索引键,表中只有一条记录与之匹配。常见于主键或唯一索引扫描
例如:explain SELECT * FROM user as a inner join `order` as b on a.id = b.uid
– ref:非唯一性索引扫描,返回匹配某个单独值的所有行。常见于使用非唯一索引即唯一索引的非唯一前缀进行的查找
例如:explain select * from `user` WHERE username = 'love001'
– index_merge: 索引合并
例如:explain SELECT * FROM `order` WHERE id = 10 and deal_id = 100
– range:限制范围的索引扫描,(=、 <>、>、>=、<、<=、BETWEEN 、 IN )
例如:explain select * from `user` WHERE id > 10 and id < 20;
– index:按索引次序扫描,先读索引,再读实际的行,不需要额外排序
例如:explain select * from `user` order by id desc;
– All:全表扫描,性能最差
例如:explain select * from user where create_time >= unix_timestamp('2017-01-01');
-
possible_keys:可能使用到的索引,如果是空的,没有相关的索引
-
key:实际使用到的索引,NULL 表示没有用到索引
-
key_len:显示使用的索引的长度,在不损失精确性的情况下,长度越短越好
-
ref:显示哪些列或常量和key中指定的索引一起做为筛选条件从表中选择数据
例如: explain select a.* from order as a inner join user as b on a.uid = b.id where b.id <=10
-
rows:查询时必须检查的行数, 预估值
-
Extra:额外补充信息
– Using filesort:排序没有用到合适的索引排序,需要做一次额外排序操作
– Using index:只使用索引中的信息,而不需要进一步读取实际的行来检索表中的信息
– Using temporary:使用到了临时表, 通常使用了 GROUP BY 或 ORDER BY 时 用到
– Using where:使用了where条件
参考:https://dev.mysql.com/doc/refman/5.7/en/explain-output.html
欢迎关注【程序员学习交流群】
-
-
gorm 强制使用索引_必看的数据库使用规范
2020-12-04 17:03:22本篇文章给大家详细分类总结了数据库相关规范,从库表命名设计规范讲起,到索引设计规范,后面又给出SQL编写方面的建议。相信这些规范适用于大多数公司,也希望大家都能按照规范来使用我们的数据库,这样我们的... -
关于MySQL数据库设计的几点优化措施
2014-12-14 20:14:56我们知道,一个好的数据库设计方案对于数据库的性能常常会起到事半功倍的效果。...无论什么设计,命名都应该作为非常重要的事情来看待,表、序列、字段、索引的命名技巧可以归结如下: (1) 序列名字跟表字段名字相同 -
关于MySQL的命名规范
2020-12-23 13:28:08数据库,表,字段,索引全部用小写英文字母,英文单词之间用下划线(_)隔开。 1.2 表字段规范 列设计规范根据业务区分使用tinyint/int/bigint,分别会占用1/4/8字节。 使用tinyint来代替enum,enum增加新值要进行DDL... -
[数据库基础]——编码标准之命名
2013-07-01 23:57:00阅读导航 表 Tables、视图 Views 存储过程Stored Procedures 触发器Triggers 索引Indexes 主键 Primary Keys ...上网找了一些SQL的开发标准文档,结合项目中的使用,写一些关于自己SQL的开发... -
必看的数据库使用规范
2019-07-20 17:01:00本篇文章给大家详细分类总结了数据库相关规范,从库表命名设计规范讲起,到索引设计规范,后面又给出SQL编写方面的建议。相信这些规范适用于大多数公司,也希望大家都能按照规范来使用我们的数据库,这样我们的... -
oracle bit类型_关于oracle中位图索引的探讨:概念、原理、优缺点
2021-01-12 14:26:02b-tree索引Oracle数据库中最常见的索引类型是b-tree索引,也就是B-树索引,以其同名的计算科学结构命名。CREATE INDEX语句时,默认就是在创建b-tree索引。没有特别规定可用于任何情况。2. 位图索引(bitmap index)... -
SQL Server 2008数据库设计与实现(关系数据库实现的通关宝典)--随书源代码
2013-02-06 12:04:004.1.5 降低每张表中索引的数量 99 4.2 规范化应该走多远 99 4.3 规范化过程 100 4.4 实体和属性的形式:第一范式 100 4.4.1 所有属性必须是原子的 101 4.4.2 实体的所有实例必须包含相同数量的值 104 4.4.3 ... -
金属材料标准的应用数据库MtrRvw
2015-11-24 17:58:10化学分析的要求统一保存在“试验要求数据表”,该表包含指向特定化学分析方法的索引。 2.3.2 机械性能、试验要求及其表达: 机械性能保存在“机械性能汇总表”; 每种试验的试验要求保存在各自的“试验要求数据表” ... -
Mysql数据库设计规范
2018-05-06 11:52:00我们在项目一开始的设计中,就要忙着考虑数据库的设计,表、字段、索引、sql等等,而在项目比较大型的时候,团队开发中由于多人同时进行,那么尽早的进行设计规范是项目开发非常关键的一步,那么关于数据库设计... -
必看的MySQL数据库使用规范
2019-10-15 11:11:19本篇文章给大家详细分类总结了数据库相关规范,从库表命名设计规范讲起,到索引设计规范,后面又给出SQL编写方面的建议。相信这些规范适用于大多数公司,也希望大家都能按照规范来使用我们的数据库,这样我们的... -
【数据库】Oracle数据库程序设计学习笔记(四)
2019-04-20 17:40:15目录 索引(INDEX) 用户管理 权限管理 ...索引(INDEX) ...索引可以分为:单列索引、复合索引 ...创建索引 ...(1)自动创建:在建表的时候,使用了 PRIMARY KEY 或 UNIQUE 约束时,...注:关于索引名的命名规范:idx... -
数据库系统基础:初级篇(第5版)(讲述数据库系统原理的经典教材)--详细书签版
2013-04-05 13:45:32ER模型和ER图,数据抽象和语义数据建模,UML类图表示法,基本关系模型,关系代数和关系演算,SQL,规范化,磁盘上组织记录文件的主要方法,文件的索引技术,查询处理与优化,以及物理数据库的设计与调优。... -
数据库系统基础:高级篇(第5版)(讲述数据库系统原理的经典教材)--详细书签版
2013-04-05 14:33:114.3.2 通过命名和可达性指定对象的持久性 69 4.4 类型、类层次和继承 70 4.4.1 类型层次和继承 70 4.4.2 对应于类型层次的外延约束 72 4.5 复杂对象 72 4.5.1 非结构化复杂对象和类型可扩展性... -
oracle 分组排序后取第一条_关于oracle中位图索引的探讨:概念、原理、优缺点...
2020-12-06 06:33:51b-tree索引Oracle数据库中最常见的索引类型是b-tree索引,也就是B-树索引,以其同名的计算科学结构命名。CREATE INDEX语句时,默认就是在创建b-tree索引。没有特别规定可用于任何情况。2. 位图索引(bitmap index)... -
Mysql数据库设计规范与性能优化
2018-05-23 13:40:56我们在项目一开始的设计中,就要忙着考虑数据库的设计,表、字段、索引、sql等等,而在项目比较大型的时候,团队开发中由于多人同时进行,那么尽早的进行设计规范是项目开发非常关键的一步,那么关于数据库设计规范... -
Oracle数据库设计规范
2020-12-11 17:59:49Oracle的关键字、保留字,详情见《关于Oracle数据库中的关键字和保留字》文件的说明。 【强制】严禁使用带空格的名称来给字段和表命名,会出错误而终止: 反例:TAB_START CROSS_TIME 【强制】用户自定义数据库... -
MySQL数据库使用规范总结
2020-12-14 08:20:33本篇文章给大家详细分类总结了数据库相关规范,从库表命名设计规范讲起,到索引设计规范,后面又给出SQL编写方面的建议。相信这些规范适用于大多数公司,也希望大家都能按照规范来使用我们的数据库,这样我们的...