parent
0382c55735
commit
f1313598c3
|
|
@ -163,6 +163,7 @@ ENTITY 表示业务实体名称，可以根据需要有多个单词组成（1-3
|
|||
视图的命名以V_开头
|
||||
##### <font color= #8470FF>Ø规范</font>：视图其它命名规范
|
||||
|
||||
|
||||
参考表的命名规范
|
||||
|
||||
##### <font color= #3CB371>Ø建议</font>：视图的列名
|
||||
|
|
@ -170,6 +171,9 @@ ENTITY 表示业务实体名称，可以根据需要有多个单词组成（1-3
|
|||
一般与基表一致，但是根据需要可以与基表的列名不同。
|
||||
|
||||
|
||||
## 索引命名规范
|
||||
##### <font color= #8470FF>Ø规范</font>：前缀规范
|
||||
索引的命名以IDX_开头,中间接表名，后面接字段名，如:IDX_TRENTBASE_PRIPID
|
||||
|
||||
# 基本设计规范
|
||||
|
||||
|
|
@ -286,3 +290,69 @@ DDL定义必须符合本设计规范，通过脚本校验工具（规避关键
|
|||
> 1. 表内的每一个记录都只能被表达一次；
|
||||
> 2. 表内的每一个记录都应该被唯一的标识（有唯一键）；
|
||||
> 3. 表内不应该存储依赖于其他键的非键信息。
|
||||
|
||||
|
||||
# 表的优化与列类的选择
|
||||
总结：数据库优化无非就两个方面：“空间换时间，时间换空间”。几十年前内存比较小，那个时候写程序就是一个字节一个字节的扣，看谁用的内存少， 现在硬件都是廉价的，1T的固态加上上百G的内存都不算什么，所以现在都是什么东西都是往内存一扔，如，以前有1G的文本，要统计数量，这个在现在就比较落伍了，直接往内存一扔，暴力统计下就可以了。第三点就是磁盘上多费点，换取时间的取胜。
|
||||
|
||||
1、定长与变长分离
|
||||
如：id int，占4个字节，char(4)占4和字符长度，也是定长。
|
||||
|
||||
即每一单元的值的字节是固定的
|
||||
核心且常用字段，宜建成定长，放在一张表
|
||||
如：用户姓名，等级是常用的，放在一张表里面，而E-mail,电话这些信息要点进去才能看，可以放在另外一张表
|
||||
|
||||
|
||||
而varchar,text,blob这种变长字段，合适存放一张表，并用主键和核心表关联起来
|
||||
|
||||
2、常用字段和不常用字段要分离
|
||||
需要结合网站具体的业务来分析，分析字段的查询场景，查询频率低的字段，拆分出来。
|
||||
|
||||
3、在一对多需要关联统计的字段上，添加冗余字段，用于统计分析
|
||||
数据库设计一般有范式，范式越高，表就拆分的越细，但是这样设计不好，我们在设计中一般是反范式。
|
||||
比如论坛，栏目，下面有个统计今日发文的数量，一般是 两表联合查询，这样比较消耗资源，我们可以添加一个【数量】的字段，每次发文就加1，每天清零，这样增加速度
|
||||
|
||||
列类型的选择
|
||||
1、字段类型的优先级：
|
||||
整型>date,time>char>varchar>text
|
||||
列的特点分析：
|
||||
1>整型：定长，没有国家、地区之分，没有字符集的差异
|
||||
比如：tinyint 1,2,3,4,5 <----> char(1) a,b,c,d,e
|
||||
从空间上，都是占用1个字节，但是 order by 排序，前者快
|
||||
原因：后者需要考虑字符集与校对集（排序规则、大小写）
|
||||
比如【 a B c D】 我们正常来说排序就是【 a B c D】 ，但是计算机是【 B D a c】
|
||||
|
||||
2>time定长，运算快，节省空间，考虑失去，写sql时不方便 where>'2005-10-12'
|
||||
3>enum 能起约束表值的目的，内部用整数型来存储，单与char联查时，内部要经历串与值的转化
|
||||
4>char 定长， 考虑字符集和排序，校对集
|
||||
5>varchar,不定长，要考虑字符集的转换与排序时的校对集，速度慢
|
||||
6>text 等大字段 无法使用内存临时表（排序操作只能在磁盘上进行）
|
||||
|
||||
以性别为例:
|
||||
char(1),3个字长字节
|
||||
enum('男','女') //内部转成数字来存，多了一个转换过程
|
||||
tingint ,//0 1 2//定长字节
|
||||
|
||||
2、够就行，不要慷慨
|
||||
原因：大的字段浪费内存，影响速度
|
||||
以年龄为例tinyint unsigned not null，可以存储255岁，足够，用int浪费了3个字节
|
||||
以varchar(100)，varchar(300)存储相同的内容，单在表联查时，varchar(300)要花更多内存
|
||||
|
||||
|
||||
3、尽量避免使用NULL()--mysql数据库的
|
||||
原因:NULL，不利于索引，要用特殊的字节来标注；
|
||||
在磁盘上占据的空间其实更大（mysql5.7已对null做了改进，但查询还是不便）
|
||||
|
||||
# 索引
|
||||
数据库查询只会用到一个索引
|
||||
|
||||
1、在where 条件常用的列上，都加上索引
|
||||
例：where id=3 and price>100 //查询栏目3，价格为100元以上的商品
|
||||
误：id上和price上都加上索引
|
||||
答：只能用上id或price索引，因为是独立的索引，同时只能用上1个
|
||||
|
||||
2、在多列上建立索引后，查询哪个列，索引都将发生作用
|
||||
误：多列索引上，索引发挥作用，需要满足左前提要求
|
||||
|
||||
# 表更新
|
||||
1、所有的执行语句必须加上事务，确定没有问题才能提交，更新数据范围不能超过100列，如果超过这个数，就必须DBA联系处理
|
||||
Loading…
Reference in New Issue