精华内容
下载资源
问答
  • 数据库设计规范

    千次阅读 2018-09-02 22:18:16
    我们或多或少的知道一些数据库设计规范,但并不全面。今天我就简单整理一下,帮自己做个总结梳理,也希望可以帮到小伙伴们。 数据库设计规范包括命名规范、库表基础规范、字段规范、索引规范和SQL设计规范。 1. ...

    数据库的重要性不言而喻。对程序员来说跟数据库打交道更是家常便饭。数据库给开发带来了巨大的便利。我们或多或少的知道一些数据库设计规范,但并不全面。今天我就简单整理一下,帮自己做个总结梳理,也希望可以帮到小伙伴们。

    数据库设计规范包括命名规范、库表基础规范、字段规范、索引规范和SQL设计规范。

    1. 命名规范

    1.1 库名、表名、字段名禁止使用MySQL保留字。


    1.2 库名、表名、字段名使用常用英语而不要使用编码,需见名知意,命名与业务、产品线等相关联。
    中文词汇的英语翻译可以参考常用术语来选择相应的英文词汇。

    1.3 库名、表名、字段名必须是名词的复数形式,并且使用小写字母,多个名词采用下划线分割单词。
    MySQL有配置参数lower_case_table_names=1,即库表名以小写存储,大小写不敏感。如果是0,则库表名以实际情况存储,大小写敏感;如果是2,以实际情况存储,但以小写比较。
    如果大小写混合使用,可能存在abc、Abc、ABC等多个表共存,容易导致混乱。
    字段名显示区分大小写,但实际使⽤时不区分,即不可以建立两个名字一样但大小写不一样的字段。
    为了统一规范, 库名、表名、字段名使用小写字母,不允许-号。

    1.4 库名、表名、字段名禁止超过32个字符。


    库名、表名、字段名支持最多64个字符,但为了统一规范、易于辨识以及减少传输量,禁止超过32个字符

    1.5 索引命名规则


    索引按照idx_table_column1_column2。其中table是建立索引的表名,column1和column2是建立索引的字段名。
    索引名限制在32个字符内。当索引名超过32字符时,可用缩写来减少索引名的长度,如description --> desc;information --> info;address --> addr等。

    1.6 主键、外键命名规则


    主键按照PK_table的规则命名,其中table为数据库表名。
    唯一键按照UK_table_column的规则命名。其中table为数据块表名,column为字段名。
    外键按照FK_parent_child_nn的规则命名。其中parent为父表名,child为子表名,nn为序列号。

    2. 库表基础规范


    2.1 使用InnoDB存储引擎。


    MySQL 5.5版本开始默认存储引擎就是InnoDB,5.7版本开始,系统表都放弃MyISAM了。

    2.2 表字符集使用UTF8MB4字符集,校验字符集使用utf8mb4_general_ci。

    UTF8字符集存储汉字占用3个字节,存储英文字符占用一个字节
    校对字符集使用默认的utf8mb4_general_ci。特别对于使用GUI工具设计表结构时,要检查它生成的SQL定义
    连接的客户端也使用utf8,建立连接时指定charset或SET NAMES UTF8;。
    如果遇到EMOJ等表情符号的存储需求,可申请使用UTF8MB4字符集

    2.3 所有表都要添加注释,除主键外的字段都需要添加注释


    类status型需指明主要值的含义,如'0-离线,1-在线'


    2.4 控制单表字段数量


    单表字段数上限30左右,再多的话考虑垂直分表,一是冷热数据分离,二是大字段分离,三是常在一起做条件和返回列的不分离。
    表字段控制少而精,可以提高I/O效率,内存缓存更多有效数据,从而提高响应速度和并发能力,后续ALTER TABLE也更快。

    2.5 所有表都必须显式指定主键


    主键尽量采用自增方式,InnoDB表实际是一棵索引组织表,顺序存储可以提高存取效率,充分利用磁盘空间。还有对一些复杂查询可能需要自连接来优化时需要用到。
    只有需要全局唯一主键时,使用外部自增id服务
    如果没有主键或唯一索引,UPDATE/DELETE是通过所有字段来定位操作的行,相当于每行就是一次全表扫描
    少数情况可以使用联合唯一主键,需与DBA协商
    对于主键字段值是从其它地方插入(非自己使用AUTO_INCREMENT生产),去掉AUTO_INCREMENT定义。比如一些31天表、历史月份表上,不要AUTO_INCREMENT属性;还有,必须通过全局id服务获取的主键,也要去掉AUTO_INCREMENT定义。

    2.6 不强制使用外键参考


    即使2个表的字段有明确的外键参考关系,也不使用FOREIGN KEY,因为新纪录会去主键表做校验,影响性能。

    2.7 适度使用视图,禁止使用存储过程、触发器和事件


    使用视图一定程度上也是为了降低代码里SQL的复杂度,但有时候为了视图的通用性会损失性能(比如返回不必要的字段)。
    存储过程(PROCEDURE)虽然可以简化业务端代码,在传统企业写复杂逻辑时可能会用到,而在互联网企业变更是很频繁的,在分库分表的情况下要升级一个存储过程相当麻烦。又因为它是不记录log的,所以也不方便调试性能问题。如果使用过程,一定考虑如果执行失败的情况。
    触发器(TRIGGER)也是同样,但也不应该通过它去约束数据的强一致性,MySQL只支持“基于行的触发”,也就是说,触发器始终是针对一条记录的,而不是针对整个sql语句的,如果变更的数据集非常大的话,效率会很低。掩盖一条SQL背后的工作,一旦出现问题将是灾难性的,但又很难快速分析和定位。再者需要DDL时无法使用pt-osc工具。放在TRANSACTION中执行。
    事件(EVENT)也是一种偷懒的表现,目前已经遇到数次由于定时任务执行失败影响业务的情况,而且MySQL无法对它做失败预警。建立专门的 job scheduler 平台。

    2.8 单表数据量控制在5000万以内


    表字段数量不要超过20个,如果有需要建立主副表,主键一一关联,避免单行数据过多以及修改记录binlog ROW模式导致文件过大。
    特别对于有一个text/blob或很大长度的varchar字段时,更应考虑单独存储。但也要注意查询条件尽量放在一个表上。

    2.9 尽量只存储单一实体类型的数据


    2.10 数据库中不允许存储明文密码


    所有的密码、scret key和SSH key等类似的保密信息,必须经过非对称加密,再保存到数据库中。

    2.11 尽量符合数据库的几个范式。


    3. 字段规范


    3.1 char、varchar、text等字符串类型定义


    对于长度基本固定的列,如果该列恰好更新又特别频繁,适合char。 utf8mb4字符集下,尽量使用varchar。varchar虽然存储变长字符串,但不可太小也不可太大。UTF8最多能存21844个汉字,或65532个英文

    varbinary(M)保存的是二进制字符串,它保存的是字节而不是字符,所以没有字符集的概念,M长度0-255(字节)。只用于排序或比较时大小写敏感的类型,不包括密码存储

    text类型与varchar都类似,存储可变长度,最大限制也是2^16,但是它20bytes以后的内容是在数据页以外的空间存储(row_format=dynamic),对它的使用需要多一次寻址,没有默认值。 一般用于存放容量平均都很大、操作没有其它字段那样频繁的值。网上部分文章说要避免使用text和blob,要知道如果纯用varchar可能会导致行溢出,效果差不多,但因为每行占用字节数过多,会导致buffer_pool能缓存的数据行、页下降。另外text和blob上面一般不会去建索引,而是利用sphinx之类的第三方全文搜索引擎,如果确实要创建(前缀)索引,那就会影响性能。凡事看具体场景。另外尽可能把text/blob拆到另一个表中

    BLOB可以看成varbinary的扩展版本,内容以二进制字符串存储,无字符集,区分大小写,有一种经常提但不用的场景:不要在数据库里存储图片。
    当字段定义为字符串形时建议使用varchar而不用nvarchar。

    3.2 int、tinyint、decimal等数字类型定义


    使用tinyint来代替enum和boolean。enum类型在需要修改或增加枚举值时,需要在线DDL,成本较高;enum列值如果含有数字类型,可能会引起默认值混淆。tinyint使用1个字节,一般用于status、type、flag的列。
    建议使用unsigned存储非负数值,相比不使用unsigned,可以扩大一倍使用数值范围。

    int使用固定4个字节存储,int(11)与int(4)只是显示宽度的区别。但是定义是bigint(20), int(11),不要随便改动这个显示宽度,c++里面需要这个长度去截取字段。
    使用decimal代替float/double存储精确浮点数。对于货币、金额这样的类型,使用decimal,如 decimal(9,2)。float默认只能精确到6位有效数字。

    3.3 timestamp与datetime选择

    datetime和timestamp类型所占的存储空间不同,前者5个字节(5.5是8字节),后者4个字节,这样造成的后果是两者能表示的时间范围不同。前者范围为1000-01-01 00:00:00 ~ 9999-12-31 23:59:59,后者范围为 1970-01-01 08:00:01 到 2038-01-19 11:14:07 。所以 timestamp 支持的范围比 datatime 要小。

    timestamp可以在INSERT/UPDATE行时,自动更新时间字段(如 set_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP),但一个表只能有一个这样的定义。

    timestamp显示与时区有关,内部总是以UTC毫秒来存的,还受到严格模式的限制。
    优先使用timestamp,datetime也没问题
    默认时间,要么CURRENT_TIMESTAMP,要么'1970-01-02 01:01:01',不要设置为''或0


    WHERE条件里不要对时间列上使用时间函数
    如果使用int类型存储时间戳,约定统一使用int unsigned default 0


    3.4 建议字段都定义为NOT NULL

    如果是索引字段,一定要定义为NOT NULL。因为NULL值会影响cordinate统计,影响优化器对索引的选择
    虽然表中允许空(NULL)列,但是,空字段是一种比较特殊的数据类型。数据库在处理的时候,需要进行特殊的处理。如此的话,就会增加数据库处理记录的复杂性。当表中有比较多的空字段时,在同等条件下,数据库处理的性能会降低许多。
    如果不能保证INSERT时该字段一定有值过来,解决方法:


    通过设置默认值的形式,定义时使用DEFAULT ''或DEFAULT 0,来避免空字段的产生。
    若一张表中,允许为空的列比较多,接近表全部列数的三分之一。而且,  这些列在大部分情况下,都是可有可无的。若数据库管理员遇到这种情况,建议另外建立一张副表,以保存这些列。

    3.5 字段的默认值


    所有字段在设计时,除timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary、varbinary这些数据类型外,必须有默认值。字符型的默认值为一个空字符值串'';数值型的默认值为数值0;逻辑型的默认值为数值0;其中,系统中所有逻辑型中数值0表示为假;数值1表示为真。

    datetime、smalldatetime类型的字段没有默认值,必须为NULL。

    3.6 同一意义的字段定义必须相同


    比如不同表中都有user_id字段,那么它的类型、字段长度要设计成一样

    4. 索引规范


    4.1 索引个数限制


    索引是双刃剑,会增加维护负担,增大I/O压力,索引占用空间是成倍增加的
    单张表的索引数量控制在5个以内,或不超过表字段个数的20%。若单张表多个字段在查询需求上都要单独用到索引,需要经过DBA评估。

    4.2 避免冗余索引

    InnoDB表是一棵索引组织表,主键是和数据放在一起的聚集索引,普通索引最终指向的是主键地址,所以把主键做最后一列是多余的。如crm_id作为主键,联合索引(user_id,crm_id)上的crm_id就完全多余
    两个索引(a,b,c)、(a,b),后者为冗余索引。可以利用前缀索引来达到加速目的,减轻维护负担

    4.3 没有特殊要求,使用自增id作为主键


    主键是一种聚集索引,顺序写入。组合唯一索引作为主键的话,是随机写入,适合写少读多的表
    主键不允许更新

    4.4 索引尽量建在选择性高的列上


    不在低基数列上建立索引,例如性别、类型。但有一种情况,idx_feedbackid_type (feedback_id, type),如果经常用type=1比较,而且能过滤掉90%行,那这个组合索引就值得创建。有时候同样的查询语句,由于条件取值不同导致使用不同的索引,也是这个道理。
    索引选择性计算方法(基数 ÷ 数据行数)
    Selectivity = Cardinality / Total Rows = select count(distinct col1)/count(*) from tbname,越接近1说明col1上使用索引的过滤效果越好
    走索引扫描行数超过30%时,改全表扫描

    4.5 最左前缀原则


    MySQL使用联合索引时,从左向右匹配,遇到断开或者范围查询时,无法用到后续的索引列。比如索引idx_c1_c2_c3 (c1, c2, c3),相当于创建了(c1)、(c1,c2)、(c1,c2,c3)三个索引,WHERE条件包含上面三种情况的字段比较则可以用到索引,但像WHERE c1=a AND c3=c只能用到c1列的索引,像c2=b AND c3=c等情况就完全用不到这个索引
    遇到范围查询(>、<、between、like)也会停止索引匹配,比如c1=a AND c2 > 2 AND c3=c,只有c1、c2列上的比较能用到索引,(c1, c2, c3)排列的索引才可能会都用上。

    WHERE条件里面字段的顺序与索引顺序无关,MySQL优化器会自动调整顺序。

    4.6 前缀索引


    对超过30个字符长度的列创建索引时,考虑使用前缀索引,如idx_cs_guid2 (cs_guid(26))表示截取前26个字符做索引,既可以提高查找效率,也可以节省空间
    前缀索引也有它的缺点是,如果在该列上ORDER BY或GROUP BY时无法使用索引,也不能把它们用作覆盖索引(Covering Index)
    如果在varbinary或blob这种以二进制存储的列上建立前缀索引,要考虑字符集,括号里表示的是字节数

    4.7 合理使用覆盖索引减少I/O

    InnoDB存储引擎中,secondary index(非主键索引,又称为辅助索引、二级索引)没有直接存储行地址,而是存储主键值。如果用户需要查询secondary index中所不包含的数据列,则需要先通过secondary index查找到主键值,然后再通过主键查询到其他数据列,因此需要查询两次。
    覆盖索引则可以在一个索引中获取所有需要的数据列,从而避免回表进行二次查找,节省I/O因此效率较高。
    例如SELECT email,uid FROM user_email WHERE uid = xx,如果uid不是主键,适当时候可以将索引添加为index(uid,email),以获得性能提升。

    4.8 尽量不要在频繁更新的列上创建索引


    如不在定义了ON UPDATE CURRENT_STAMP的列上创建索引,维护成本太高(好在MySQL有insert buffer,会合并索引的插入)

    4.9 修改表结构DROP COLUM时要注意


    与这个字段相关的索引都会改变,变化是从原索引抽掉该字段定义。这种情况有可能导致部分索引重复或失效。

    5. SQL设计规范


    5.1 所有关键字的所有字母必须大写


    5.2 杜绝直接SELECT *读取全部字段


    即使需要所有字段,明确指定所需字段也能减少网络带宽消耗,能有效利用覆盖索引,表结构变更对程序基本无影响。

    5.3 能确定返回结果只有一条时,使用LIMIT 1

    在保证数据不会有误的前提下,能确定结果集数量时,多使用LIMIT,尽快地返回结果。

    5.4 小心隐式类型转换


    转换规则


    两个参数至少有一个是NULL时,比较的结果也是NULL,例外是使用<、=、>对两个NULL做比较时会返回1,这两种情况都不需要做类型转换
    两个参数都是字符串,会按照字符串来比较,不做类型转换
    两个参数都是整数,按照整数来比较,不做类型转换
    十六进制的值和非数字做比较时,会被当做二进制串
    有一个参数是timestamp或datetime,并且另外一个参数是常量,常量会被转换为timestamp

    有一个参数是decimal类型,如果另外一个参数是decimal或者整数,会将整数转换为decimal后进行比较,如果另外一个参数是浮点数,则会把decimal转换为浮点数进行比较
    所有其他情况下,两个参数都会被转换为浮点数再进行比较。


    如果一个索引建立在string类型上,如果这个字段和一个int类型的值比较,符合第 7 条。如phone定义的类型是varchar,但WHERE使用phone in (098890),两个参数都会被当成成浮点型。发生这个隐式转换并不是最糟的,最糟的是string转换后的float,MySQL无法使用索引,这才导致了性能问题。如果是user_id = '1234567' 的情况,符合第 2 条,直接把数字当字符串比较。

    5.5 禁止在WHERE条件列上使用函数


    会导致索引失效,如LOWER(email),qq % 4。可放到等号右边的常量上计算
    返回小结果集不是很大的情况下,可以对返回列使用函数,简化程序开发

    5.6 使用LIKE模糊匹配,%不要放首位


    会导致索引失效,有这种搜索需求是,考虑其它方案,如sphinx全文搜索

    5.7 涉及到复杂SQL时,务必先参考已有索引设计,先EXPLAIN

    简单SQL拆分,不以代码处理复杂为由。
    比如OR条件: phone=’10000’ OR mobile=’10000’,两个字段各自有索引,但只能用到其中一个。可以拆分成2个sql,或者UNION ALL。
    先EXPLAIN的好处是可以为了利用索引,增加更多查询限制条件

    5.8 使用JOIN时,WHERE条件尽量使用充分利用同一表上的索引


    如 SELECT t1.a, t2.b * FROM t1, t2 AND t1.a=t2.a AND t1.b=123 AND t2.c= 4,如果t1.c与t2.c字段相同,那么t1上的索引(b, c)就只用到b了。此时如果把WHERE条件中的t2.c=4改成t1.c=4,那么可以用到完整的索引
    这种情况可能会在字段冗余设计(反范式)时出现
    正确选取INNER JOIN和LEFT JOIN。不允许滥用LEFT JOIN。

    5.9 少用子查询,改用JOIN

    小于5.6版本时,子查询效率很低,不像Oracle那样先计算子查询后外层查询。5.6版本开始得到优化。

    5.10 考虑使用UNION ALL,少使用UNION,注意考虑去重

    UNION ALL不去重,而少了排序操作,速度相对比UNION要快,如果没有去重的需求,优先使用UNION ALL

    如果UNION结果中有使用LIMIT,在2个子SQL可能有许多返回值的情况下,各自加上LIMIT。如果还有ORDER BY,请找DBA。

    5.11 IN的内容尽量不超过200个


    超过500个值使用批量的方式,否则一次执行会影响数据库的并发能力,因为单SQL只能且一直占用单CPU,而且可能导致主从复制延迟。

    5.12 拒绝大事务


    比如在一个事务里进行多个SELECT,多个UPDATE,如果是高频事务,会严重影响MySQL并发能力,因为事务持有的锁等资源只在事务ROLLBACK/COMMIT时才能释放。但同时也要权衡数据写入的一致性。不要再事务里面做除数据库以外的操作。

    5.13 避免使用IS NULL, IS NOT NULL这样的比较


    5.14 ORDER BY .. LIMIT

    这种查询更多的是通过索引去优化,但ORDER BY的字段有讲究,比如主键id与time都是顺序递增,那就可以考虑ORDER BY id而非 time

    5.15 c1 < a ORDER BY c2


    与上面不同的是,ORDER BY之前有个范围查询,由前面的内容可知,用不到类似(c1,c2)的索引,但是可以利用(c2,c1)索引。另外还可以改写成JOIN的方式实现。

    5.16 分页优化


    建议使用合理的分页方式以提高分页效率,大页情况下不使用跳跃式分页
    假如有类似下面分页语句:


      SELECT FROM table1 ORDER BY ftime DESC LIMIT 10000,10;
    这种分页方式会导致大量的I/O,因为MySQL使用的是提前读取策略。
      推荐分页方式:

      SELECT FROM table1 WHERE ftime < last_time ORDER BY ftime DESC LIMIT 10
    即传入上一次分页的界值。或者:

      SELECT * FROM table as t1 inner JOIN (SELECT id FROM table ORDER BY time LIMIT 10000,10) as t2 ON t1.id=t2.id

    5.17 COUNT计数


    首先COUNT()、COUNT(1)、COUNT(col1)是有区别的,COUNT()表示整个结果集有多少条记录,COUNT(1)表示结果集里以主键统计数量,绝大多数情况下COUNT()与COUNT(1)效果一样的,但COUNT(col1)表示的是结果集里col1列NOT NULL的记录数。优先采用COUNT()

    大数据量COUNT是消耗资源的操作,甚至会拖慢整个库,查询性能问题无法解决的,应从产品设计上进行重构。例如当频繁需要COUNT的查询,考虑使用汇总表
    遇到DISTINCT的情况,GROUP BY方式可能效率更高。

    5.18 DELETE、UPDATE语句改成SELECT再EXPLAIN


    SELECT最多导致数据库慢,写操作才是锁表的罪魁祸首

    5.19 减少与数据库交互的次数,尽量采用批量SQL语句

    INSERT ... ON DUPLICATE KEY UPDATE ...,插入行后会导致在一个唯一索引或主键中出现重复值,则执行旧行UPDATE,如果不重复则直接插入,影响1行。

    REPLACE INTO类似,但它是冲突时删除旧行。INSERT IGNORE相反,保留旧行,丢弃要插入的新行。

    INSERT INTO VALUES(),(),(),合并插入。

    5.20 杜绝危险SQL


    去掉WHERE 1=1这样无意义或恒真的条件,如果遇到UPDATE/DELETE或遭到SQL注入就恐怖了
    SQL中不允许出现DDL语句。一般也不给予CREATE/ALTER这类权限,但阿里云RDS只区分读写用户

    5.21 是否应该ORDER BY主键


    许多排序的场景,如果主键id是增长的,如果ORDER BY create_time查询慢,有可能使用了filesort,此时最简单的办法是看能否换成ORDER BY id,因为id作为主键是递增的,并且附带在了每个二级索引后面。
    但是也要谨慎使用 ORDER BY id,特别是在EXPLAIN结果看到filesort的情况下,优化器极有可能放弃这个filesort,而选择了它所认为更高效的扫描方式,实则更慢。

    5.22 使用正确的表


    比如要统计昨天的数据这类业务较多,是否可以设计一个昨天表,不在31天表上统计,在月份表上统计也行。或者其它组已经有“半统计”的数据,从他们那抽取数据,而不是在原始数据上统计。

    展开全文
  • 电商数据库设计 mysql 数据库设计规范

    生产环境如下

    MySql 版本 MySql 5.7
    图形管理工具Navicat
    Linux 系统

    项目说明

    电商的基本模块有如下几个, 按照用户使用的流程

    Created with Raphaël 2.1.0用户登录选购商品加入购物车检查库存提交订单货到付款?发货订单付款yesno

    通过流程图 , 我们需要设计以下几个模块

    模块 模块说明
    用户模块 完成用户注册和登录验证
    商品模块 前后台商品管理和浏览
    订单模块 订单及购物车的生成和管理
    仓配模块 仓库库存和物流管理

    接下来就是数据库设计, 先说一说数据库的设计规范

    在实际工作中,一般情况下,各个公司都有自己的数据库设计规范,在遵循公司内部规范的同时,我们还有业内共识通用的设计规范,在此,就本次的电商数据库设计,说明以下部分规范.这个规范也同样适用与大部分业务的数据库设计.

    数据库命名规范

    • 所有的数据库对象名称必须使用小写字母并使用下划线分割(mysql 数据库对大小写敏感)
    • 所有数据库对象名称禁止使用MySqL保留关键字 eg. from关键字
    • MySQL关键字查询
    • 数据库对象的命名要见名之意 , 最好不要超过32个字符.
    • 数据库操作的时候 ,总会导入导出表 , 有一些临时表 , 临时表的最好以tmp为前缀并且以日期为后缀
    • 备份表的命名, 最好以bak为前缀并且以日期为后缀
    • 所有存储相同数据的列名和列类型必须一致

    数据结构基本设计规范

    • 所有的表必须使用Innodb存储引擎
      MySQL5.6 以后 Innodb 引擎成了默认的存储引擎 . 支持事务,行及锁,有更好的恢复性,高并发下性能好

    • 数据库和标的字符集统一使用UTF-8
      MySQL UTF-8字符集汉子占3个字节 , ASSIC占1个字节

    • 所有的表和字段都要添加注释

    • 尽量控制单表数据量的大小 , 尽量在500万行以内
      如果必须超过这个量 , 一般采用历史数据归档(eg. 日志类表) , 分库分表(主要是业务数据)等方式.

    • 尽量做到冷热数据分离,减小表的宽度
      这样做的目的是较少磁盘的IO , 保证热数据的内存缓存命中率
      利用更有效的利用缓存,避免读入更无用的冷数据(少使用 select *)
      经常使用的列放到一个表中

    • 禁止在表中建立预留字段
      很难做到见名之意
      无法确认存储的数据类型.
      对预留字段进行修改时,会对表造成锁定

    • 禁止在数据库中存储图片, 文件等二进制数据 .

    • 禁止在线上数据库做数据库压力测试

    • 禁止从开发环境,测试环境直连生产环境数据库
      否则很容易造成数据库污染

    数据库索引设计规范

    • 限制每张表的上的索引数量 , 建议单张表索引不超过 5 个

      • Innodb是按照主键的顺序来组织表的
      • 不使用更新频繁的列作为主键 , 不使用多列主键
      • 不使用UUID , MD5 , HASH , 字符串列作为主键
      • 主键建议使用自增ID使用主键
    • 常见索引列建议

      • select ,update , delete 语句中的where 从句中的列
      • 包含在order by ,group by ,distinct 中的字段
      • 多表JOIN的关联列
    • 如何选择索引列的顺序
      • 区分度最高的列放在联合索引的最左侧(主键, 唯一索引列)
      • 尽量把字段长度最小的列放在联合索引的最左侧
      • 使用频繁的列放到最左侧

    数据字段设计规范

    • 优先选择符合存储需要的最小的数据类型

      • 将字符串转化为数字类型存储 INET_ATON('255.255.255.255') = 429467295 IETN_NTOA(429467295) = '255.255.255.255'
      • 对于非负整数来说, 优先使用无符号整型
      • MySQL 中 varchar(n) 这里的n 代表的是字符数 , 不是字节数 ,varchar(255) 可以存 255 个汉字 , 需要占用 765 个字节
      • 过大的长度会消耗更多的内存
    • 避免使用 TEXT , BLOB数据类型

      • 如果必须使用 , 将BLOB或者是TEXT列分离到单独的扩展表
    • 避免使用 ENUM数据类型

    • 尽可能把列定义为 NOT NULL

    • 使用 timestamp 或者datetime 类型存储时间

      • timestamp 存储时间 范围 为 1970-01-01 00:00:01 ~ 2038-01-19 03:14:07

      • timestamp 区间不够, 使用datetime 存储

    • 同财务相关的金额类数据 , 必须使用 decimal 类型

      • decimal 类型为精准浮点数 , 在计算时不会丢失精度

    数据库SQL开发规范

    • 充分使用表已经存在的索引查询

      • 使用left join 或者 not exists 优化 not in 操作
    • 禁止使用 select * 查询

      • 会消耗更多的cpu 和io 以及网络带宽资源
      • 无法使用覆盖索引
      • 可较少表结构变更带来的影响
    • 禁止使用不含字段列表的 insert 语句

    • 避免使用子查询 , 可以把子查询优化 join 操作

      • 子查询结果集无法使用索引
      • 子查询会产生临时表操作 , 如果子查询数据量大则严重影响效率
    • 避免使用 join 关联太多的表

      • 建议不超过 5 个
    • 减少同数据库的交互次数

      • 数据库更适合处理批量操作
    • 使用 in 代替 or

    • 禁止使用 order by rand () 进行随机排序

    • where 从句中禁止对列进行函数转换和计算

      • where date(createtime) = ‘20170101’ (禁止这样)
      • 上面的可以这样改 where createtime >='20170101' and createtime <'20170102'
    • 再明显不会有重复值时 使用 union all 而不是 union

    • 拆分复杂的大 sql 为多个 小 sql

    数据库操作行为规范

    • 超过 100 万行的批量写操作 ,要 分批分次进行操作

    • 禁止为程序使用的账号赋予super 权限

    • 对于程序连接数据库账号 , 遵循权限最小原则

      • 程序使用数据库账号只能在一个DB下使用 , 不准跨库
      • 程序使用的账号原则上不准有 drop 权限
    展开全文
  • SQL Server数据库设计规范

    千次阅读 2017-06-16 16:25:40
    数据库设计规范 1.简介 数据库设计是指对一个给定的应用环境,构造最优的数据库模式,建立数据库及其他应用系统,使之能有效地存储数据,满足各种用户的需求。数据库设计过程中命名规范很是重要,命名规范合理的...

    数据库设计规范

    1.简介

    数据库设计是指对一个给定的应用环境,构造最优的数据库模式,建立数据库及其他应用系统,使之能有效地存储数据,满足各种用户的需求。数据库设计过程中命名规范很是重要,命名规范合理的设计能够省去开发人员很多时间去区别数据库实体。

    最近也因为工作需要所以整理出了这个word文档,望大家指正。

     

    2数据库设计

    数据库规划→需求分析→数据库设计→应用程序设计→实现→测试→运行于维护

    2.1数据库规划

    定义数据库应用系统的主要目标,定义系统特定任务,包括工作量的估计、使用资源、和需求经费,定义系统的范围以及边界。

    2.2需求分析

    2.1.1需求分析步骤与成果

    涉及人员:用户和分析人员

    任务:对现实世界要处理的对象进行详细的调查,收集基础数据及处理方法,在用户调查的基础上通过分析,逐步明确用户对系统的需求,包括信息的要求及处理的要求。

    方法与步骤:1.通过与用户的调查,对用户的信息需求进行收集。

    2.在收集数据的同时,设计人员要对其进行加工和整理,以数据字典和数据流图的形式描述出来,并以设计人员的角度向用户讲述信息,根据用户的反馈加以修改并确定(该过程是反复的过程)

    成果:数据流图,数据字典,各种说明性表格,统计输出表以及系统功能结构图。

    2.1.2数据流图基本元素与数据流图

    外部实体:存在于软件系统之外的人员或组织(正方形或立方体表示)。

    加工:数据处理,表示输入数据在此进行变换,产生输出数据(圆角巨型或圆形表示)。

    数据流:表示流动着的数据(箭头线表示)。

    数据存储:用来表示要存储的数据(开门矩形或两条平行横线表示)。

     

     

     

    订单处理系统顶层流程图:

    0层数据流图:

                                        

     

     

    2.3数据库设计

    2.3.1概念结构设计

    • 对事务加以抽象以E-R图的形式描述出来
    • E-R图(实体联系图):包括实体,联系,属性

    实体:现实中的事物例如,学生,老师

    联系:两个实体之间的关系,1:1、1:N、M:N三种关系

    属性:实体所具有的属性,例如 学生的学号、姓名、性别等

    例如:一个学生属于一个班级,一个班级拥有多名学生,E-R图如下

     

     

     

    网上购物系统E-R图,该系统数据之间存在下列约束

     

    1. 一个客户(编号唯一)可以拥有多个订单,每个订单仅属于一个客户。
    2. 一个订单(编号唯一)可以包含多个订购细目,每个订购细目只属于一个订单。
    3. 一个商品可以出现多个订购细目中,一个订购细目只包含多个商品。
    4. 一个商品类别可以包含多种商品,一种商品只属于一个商品类别。

     

     
     

     

    图2.2

    2.3.2逻辑结构设计

    2.3.2.1E-R图转换成关系模式

    •  将E-R图转换成关系模式

    将每个实体转换成一个关系模式,实体的属性即关系模式的属性,实体的标识即关系模式的键。

    •  根据规则合并E-R图中的1:1,1:N,M:N之间的联系
    1. 若实体的联系是(1:1),则可以将两个实体转换成两个关系模式,任意一个关系模式的属性中加入另一个关系模式的主键(作为外键)和联系自身的属性
    2. 若实体间的联系是一对多(1:n),则将n端的实体类型转换成关系模式中加入1端实体类型的主键(作为外键)和联系类型的属性。
    3. 若实体间的联系是多对多(m:n),则将联系类型也转换成关系模式,其属性为2实体类型的主键(作为外键)加上联系类型自身的属性,而该关系模式的主键为2端实体主键的组合。
    4. 若关系模式是1:1:1的关系,转换原则同1:1
    5. 若关系模式是1:1:n的联系,转换原则同1:n
    6. 若关系模式是1:n:m的联系,则可以将联系类型也转换成关系模式,其属性为m端和n端实体类型的主键(作为外键)加上联系类型自身的属性,而关系模式的主键为n和m端实体主键的组合
    7. 若关系模式是n:m:p的联系,转换规则同m:n

    根据E-R图实体之间的联系可以转换成以下关系模式

    客户(客户编号,姓名,电话,E-mail)。关系的主键:客户编号;外键:无

    订单(订单编号,订购时间,客户编号)。关系的主键:订单编号;外键:客户编号

    订购细目(订购明细编号,订购数量,支付金额,订单编号)。关系主键:订购明细编号;外键:订单编号。

    出现(订购明细编号,商品编号,类型)。关系的主键:订购明细编号,商品编号;外键:订购明细编号,商品编号。

    商品:(商品编号,商品名称,单价,生产日期,商品类别号,商品类别名)。关系的主键:商品编号;外键:无

    在关系模式设计中可能会出现以下几个问题:数据冗余、数据修改不一致、数据插入异常、数据删除异常,所以提出范式的要求,目的就是最低限度地冗余,避免插入、删除、修改异常。

    2.3.2.2范式

    主属性:包含键的所有属性。

    •  关系模式要求达到4NF (减少冗余,消除操作异常)

    第一范式(1NF):若关系模式R的每一个分量是不可分的数据项,则关系模式属于第一范式。即每个属性都是不可拆分的.

    第二范式(2NF):R属于1NF,且每一个非主属性完全依赖于键(没有部分依赖),则R属于2NF

    例如:选课关系(学号,课程号,成绩,学分)

    该关系的主键是(学号,课程号),但是课程号→学分,所以学分属性部分依赖于主键,即关系部满足第二范式,可以拆分为(学号,课程号,成绩),(课程号,学分)两个关系

    第三范式(3NF):R属于2NF,且每个非主属性即不部分依赖于码,也不传递依赖于码

    例如:学生关系(学号,姓名,所属系,系地址)

    该关系的主键是:学号

    学号→所属系,所属系→学号,所属系→系地址;根据函数的依赖公理,系地址传递函数依赖于学号,即关系不满足第三范式,可以拆分关系为(学号,姓名,所属系),(所属系,系地址)

    如果不拆分会存在数据修改异常,比如该学生的换了系,修改了所属系,但是系地址没有修改,这样就造成了修改异常

     BCNF:R属于3NF,且不存在主属性对码的部分和传递函数依赖

    例如:关系R(零件号,零件名,厂商名),如果设定每种零件号只有一个零件名,但不同的的零件号可以有相同的零件名,每种零件可以有多个厂商生产,但每家厂商生产的零件应有不同的零件名。这样可以得到:

    零件号→零件名,(厂商名,零件名)→零件号

    所以主属性包括(零件号,厂商名,零件名),但是“零件名”传递依赖于码“厂商名,零件名”,所以关系R不满足BCNF,当一个零件由多个生产厂商生产时,由于零件号只有一个而零件名根据厂商不同而又多个,零件名与零件号之间的联系将多次重复,带来数据冗余和操作异常现象

    可以将关系分解为(零件号,厂商名),(零件号,零件名)

    4NF:关系模式R属于1NF,若对于R的每个非平凡多值依赖X→→Y且Y不包含于X时,X必含码,则R属于4NF

    5NF:对关系进行投影,消除关系中不是由候选码所蕴含的连接依赖

    对于上面的商品关系,由于关系的主键是商品编号,而商品类别号→商品类别名

    所以商品关系部满足第三范式,非主属性商品类别名传递依赖于商品编号,会存在数据冗余,数据修改异常问题。将商品关系分解为:

    商品(商品编号,商品名称,单价,生产日期,商品类别号)

    商品类别(商品类别号,商品类别名)

    2.3.3物理结构设计

    为一个给定的逻辑数据模型设计一个最合适应用要求的物理结构的过程

    •  数据库的建立
    •  数据表的建立
    •  索引的建立
    •  视图的建立
    •  触发器的建立
    •  存储过程设计
    • 用户自定义函数设计
    •  对关系模式的数据项加以约束,如检查约束、主键约束、参照完整性约束以保证数据正确性

     

    2.4应用程序设计

    采用高级语言以结构化设计方法或面向对象方法进行设计

    2.5系统实现

     

    3.优化策略

    3.1.查询优化策略

    1. 尽可能地减少多表查询或建立物化视图
    2. 只检索需要的列
    3. 用带IN的条件字句等级替换or字句
    4. 经常提交COMMIT,以尽早释放锁

     

    3.2表设计

    1.如果频繁地访问涉及的是对两个相关的表进行连接操作,则考虑将其合并

    2.如果频繁地访问只是在表中的某一部分字段上进行,则考虑分解表,将该部分单独作为一个表

    3.对于很少更新的表,引入物化视图

    4. 当系统中有一些少量的,重复出现的值时,使用字典表来节约存储空间和优化查询。如地区、系统中用户类型的代号等。这类值不会在程序的运行期变化,但是需要存储在数据库中。

       就地区而言,如果我们要查询某个地区的记录,则数据库需要通过字符串匹配的方式来查询;如果将地区改为一个地区的代号保存在表中,查询时通过地区的代号来查询,则查询的效率将大大提高。

    程序中宜大量的使用字典表来表示这类值。字典表中保存这类值的代号和实体的集合,以外键的方式关联到使用这类值的表中。然而,在编码阶段,程序员并不使用字典表,因为首先查询字典表中实体的代号,违背了提高查询效率的初衷。程序员在数据字典的帮助下,直接使用代号来代表实体,从而提高效率。

    虽然字典表在实际上并不使用,但是仍应该保留在数据库中(起码是在开发期内保留)。字典表作为另一种形式上的“数据字典文档”出现,以说明数据库中哪些表的哪些字段是使用了字典表的。

    为了提高数据库的数据完整性,在开发阶段可以保留完整的字典表和普通表的外键约束。但是在数据库的运行阶段,应该将普通表和字典表的外键删除,以提高运行效率,特别是某些表使用了很多字典表的情况。

     

       案例:某数据库中有百万条用户信息,应用系统中常常需要按照地区要查询用户的信息。用户信息表以前是按照具体的地区名称来保存的,现在将具体的名称改为字典表中的地区代号,查询效率大大提高。

     

    3.3索引

    1. 如果查询是瓶颈,则在关系上建立适当的索引;通常,作为查询条件的属性上建立索引可以提高查询效率。
    2. 如果更新是瓶颈,因为每次更新都会重建表上的索引,引起效率降低,则考虑删除某些索引。
    3. 选择适当索引,如果经常使用范围查询,则B树索引比散列索引更高效
    4. 将有利于大多数查询和更新的索引设为聚集性索引。

     

    3.4提高IO效率

    1. 索引文件和数据文件分开存储,事务日志文件存储在高速设备上
    2. 经常修改数据文件和索引文件的页面大小
    3. 定期对数据进行排序
    4. 增加必要的索引项

    4.数据库命名规范

    4.1数据库对象

    对象

    前缀

    数据库

    视图

    VI

    索引

    IX

    存储过程

    SP

    函数

    FN

    触发器

    TR

    自定义数据类型

    ud

    Default

    DF

    主键

    pk

    外键

    FK

    rule

    ru

    序列

    Sq

    UNIQUE

    uq

    数据库对象采用26个英文字母(区分大小写)和0-9这十个自然数,加上下划线_组成,共63个字符。不能出现其他字符(注释除外)。

    同一个数据库中这些对象名都是不能重复

    C    CHECK_CONSTRAINT

    D    DEFAULT_CONSTRAINT

    F    FOREIGN_KEY_CONSTRAINT

    IT   INTERNAL_TABLE

    P    SQL_STORED_PROCEDURE

    PK   PRIMARY_KEY_CONSTRAINT

    S    SYSTEM_TABLE

    SQ   SERVICE_QUEUE

    TR   SQL_TRIGGER

    U    USER_TABLE

    UQ   UNIQUE_CONSTRAINT

    V    VIEW

    4.2命名规范规定

    1.表名使用单数名

    例如:对存储客人信息的表(Customer)不使用Customers

    2.避免无谓的表格后缀

    1、 表是用来存储数据信息的,表是行的集合。那么如果表名已经能够很好地说明其包含的数据信息,就不需要再添加体现上面两点的后缀了。

    2、  GuestInfo(存储客户信息)应写成Guest,FlightList(存储航班信息的表)应写成Flight

    3.所有表示时间的字段,统一以 Date 来作为结尾(而不是有的使用Date,有的使用Time)

    以大家都熟悉的论坛来说,需要记录会员最后一次登录的时间,这时候一般人都会把这个字段命名为LoginTime 或者 LoginDate。这时候,已经产生了一个歧义;如果仅看表的字段名称,不去看表的内容,很容易将LoginTime理解成登录的次数,因为,Time还有一个很常用的意思,就是次数

    4.所有表示数目的字段,都应该以Count作为结尾

    5.所有代表链接的字段,均为Url结尾

    6.所有名称的字符范围为:A-Z, a-z, 0-9 和_(下划线)。不允许使用其他字符作为名称。

    7.采用英文单词或英文短语(包括缩写)作为名称,不能使用无意义的字符或汉语拼音。

    8.名称应该清晰明了,能够准确表达事物的含义,最好可读,遵循“见名知意”的原则。

     

    4.3数据库命名规范

    数据库名称不需要简写,根据实际意义来命名。例如:ReportServer

    数据库名:ReportServer

    逻辑数据名:ReportServer;逻辑日志名:ReportServer_log

    物理数据名:ReportServer.mdf;物理日志名:ReportServer_log.LDF

    CREATE DATABASE [ReportServer] ON  PRIMARY

    ( NAME = N'ReportServer', FILENAME = N'D:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\useData\ReportServer.mdf' , SIZE = 3328KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )

     LOG ON

    ( NAME = N'ReportServer_log', FILENAME = N'D:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\useData\ReportServer_log.LDF' , SIZE = 6400KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)

    Go

    注意:避免所有数据库的逻辑名称使用相同的名称。

    4.4表设计命名规范

    注意字段名不能使用保留关键字:如action,avg等

    1、不使用tab或tbl作为表前缀(本来就是一个表,为什么还要说明)

    2、表名以代表表内的内容的一个和多个名词组成,以下划线分隔,每个名词的第一个字母大写,例如:User、UserLogin,UserGroupRelation等

    3、使用表的内容分类作为表名的前缀:如,与用户信息相关的表使用前缀User,与内容相关的信息使用前缀Content。

    4、表的前缀以后,是表的具体内容的描述。如:用户登录信息的表名为:UserLogin,用户在论坛中的信息的表名为:UserBBSInfo

    5、一些作为多对多连接的表,可以使用两个表的前缀作为表名:

             如:用户登录表UserLogin,用户分组表GroupInfo,这两个表建立多对多关系的表名为:UserGroupRelation

    4.4.1字段命名规范

    1. 字段名不要存在无用前缀,例如表‘WeiXinConfig’,既然我已经知道这张表是关于微信的表,里面的名称字段可以可以使用Name,不需要添加无用的前缀类似‘WeiXinName’,‘WeiXinGuanZhuMsg’,‘WeiXinUpImgMsg’等
    2. 字段使用实际英文翻译作为命名字段,见名知意,不要使用让人看了半天都不知道是啥意思的字段(类似:lev1,lev2…)

    4.5存储过程命名

    存储过程名=[SP_]+[表名]+[操作名字]

    [操作名字]=[insert|delete|update|calculate|confirm]

    例如:SP_community_update

    4.5.1只允许应用程序通过存储过程访问数据库

       只允许应用程序通过存储过程访问数据库,而不允许直接在代码中写SQL语句访问数据库。

    在数据库开发项目中,大量使用存储过程有很多的好处,首先看微软提供信息:

     

     

    使用 SQL Server 中的存储过程而不使用存储在客户计算机本地的 Transact-SQL 程序的优势有:

    允许模块化程序设计:

    只需创建过程一次并将其存储在数据库中,以后即可在程序中调用该过程任意次。存储过程可由在数据库编程方面有专长的人员创建,并可独立于程序源代码而单独修改。

    允许更快执行:

    如果某操作需要大量 Transact-SQL 代码或需重复执行,存储过程将比 Transact-SQL 批代码的执行要快。将在创建存储过程时对其进行分析和优化,并可在首次执行该过程后使用该过程的内存中版本。每次运行 Transact-SQL 语句时,都要从客户端重复发送,并且在 SQL Server 每次执行这些语句时,都要对其进行编译和优化。

    减少网络流量:

    一个需要数百行 Transact-SQL 代码的操作由一条执行过程代码的单独语句就可实现,而不需要在网络中发送数百行代码。

    可作为安全机制使用:

    即使对于没有直接执行存储过程中语句的权限的用户,也可授予他们执行该存储过程的权限。

     

     

     

       除此以外,使用存储过程的好处还有:

    1、  在逻辑上,存储过程将应用程序层和数据库物理结构分离开来。存储过程形成了一个应用程序和数据库之间的接口。这样的接口抽象了复杂的数据库结构,符合极限编程中“基于接口编程”的思想。

    2、  将主要的业务逻辑封装在存储过程中,能够避免在应用程序层写大量的代码(在应用程序中通过字符串插入太长的SQL语句影响效率,而且维护困难)。有助于提高开发效率,并且直接在查询分析器中调试存储过程,能够更早的发现系统中的逻辑问题,从而提高代码的质量。

    3、  在网站一类的应用系统中,SQL注入式漏洞一直是难以完全杜绝的漏洞。如果只通过存储过程来访问数据库,能够大大减少这类安全性问题。(因此,就算是简单的只有一句的SQL语句,也应该写成存储过程。)

    4、  由于采用存储过程,应用程序的层面可以不关心具体的数据库结构,而只关心存储过程的接口调用。因此,在以下一些情况,存储过程的优势非常明显:

    ·需求变更,表的结构必须要改变。使用存储过程,只要参数不变,我们就只需要修改相应的存储过程,而不需要修改应用程序的代码。这样的设计将减小需求变更对项目的影响。

    ·为提高效率,使部分字段冗余:一些经常性访问的字段,我们可以在相关的表中进行冗余存储。这样既提高了效率,又通过存储过程屏蔽了冗余细节。

    ·为提高效率,使用冗余表(拆分表):一些大的表,为了提高查询效率,可能需要将记录分别保存到多个表中去。使用存储过程,有存储过程来决定从哪些拆分的表中获取或插入数据。这样提高了效率,又不必在应用程序层面关心具体的拆分规则。

    5、 使用存储过程,便于在项目后期或者运行中集中优化系统性能。在项目开发过程中,由于各种原因,往往无法编写高效的代码,这个问题常常在项目后期或者在运行期体现出来。通过存储过程来封装对数据库的访问,可以在项目集成以后,通过试运行观察系统的运行效率,从而很容易找出系统的瓶颈,并能够通过优化存储过程的代码来提高系统的运行效率。这样的优化,比在运用程序中优化更有效,更容易。

     

    同时,过多的使用存储过程,也存在以下一些疑虑:

    问题一:存储过程编译后,将作为数据库的全局对象保存,太多的存储过程将占用大量的数据库服务器的内存。

    问题二:在存储过程中实现大量的逻辑,将使大量的运算在数据库服务器上完成,而不是在应用服务器上完成。当访问量很大的时候,会大大消耗数据库服务器的CPU占用率。

    在此还存在这个一个案例:有一个访问量巨大的网站,有多台WEB服务器构成一个负载均衡的服务器群集,但是只有一台中心的数据库服务器。当访问量持续增加的时候,接入更多的WEB服务器来满足高并发量的访问;但是数据库服务器却没办法一直增加。因此,就需要尽量在WEB服务器上完成业务逻辑,尽量避免消耗数据库服务器的资源。

     

       对于这两个担心,我的想法是:

    问题一的解决:存储过程是经过编译后的SQL语句,在内存中是二进制的代码,并不会消耗太多内存。并且,存储过程比起直接使用SQL语句来说,效率大大提高。换个角度来说,这是一个“以空间换时间”的方案,多消耗一点内存来换取效率的提高,是值得的。

    问题二的解决:首先,在实现业务逻辑的问题上,在存储过程中实现比在应用程序中实现更容易;其次,从开发效率上,存储过程的开发比应用程序更简单(就完成相同逻辑而言)。在高访问量的系统中,应用服务器和数据库服务器的资源分配的问题,应该从成本的角度来开率:软件开发中的成本,人工支出的费用远远高于硬件支出的成本。我们可以很容易花钱购买更好的服务器,但是很难花钱让开发人员使程序有大幅度的提高。

    使用存储过程来封装业务逻辑,首先节省的是大量的开发时间和调试时间,并能够大大提高代码的质量。因此,从成本来说,应该使用存储过程。

    对于大访问量的情况,最简单的办法是投入更多的硬件成本:更快的硬盘,更大的内存和更多的CPU,还有更好的网卡…………等等。

    其次,在应用程序的层面,可以大量的使用静态文件缓存的办法来减轻数据库的压力。如:不经常变化的信息,可以从数据库服务器中读取,保存为应用服务器上的XML静态文件等。

    实在不行的话,应该在系统设计之初,考虑可能的访问量,将系统设计成分布式的。这样就能从根本上解决大访问量的问题。

     

    4.5.2命名规范

    1、存储过程的前缀和表名的前缀类似:把一系列表看成一个对象,字段为对象的属性,存储过程则为访问对象的方法。如:添加用户的存储过程取名为:User_AddUser

    2、存储过程使用模块的前缀来命名。如,用户管理的存储过程使用前缀user_。

    3、存储过程的前缀之后,是动词+名词形式的存储过程名(也可以是动词短语)。

    4.5.3存储过程的参数命名

    1、参数名采用匈牙利命名法,使用类型的前缀

    2、每个存储过程都有:@errno int和@errmsg varchar(255)两个输出参数。应用程序中可以根据这两个参数得到存储过程执行的情况。(这两个参数使用默认值,可以忽略)

    errno为整型的错误信息代码,执行成功返回0。Errno的值的具体含义通过errmsg参数说明,或者通过代码中的注释或文档。

    Errmsg为错误信息的字符串描述,这个参数主要用于调试期作为说明,避免在应用程序中使用该值。同时,要注意英文版系统和中文版系统中,信息的语言选择对程序的影响。

    4.5.4存储过程返回的记录集

    1、存储过程的输出记录集:为程序的结构清晰,存储过程最好只返回一个记录集。但在某些为了提高性能的场合,还是可以输出多个记录集

    2、记录集中,每个输出的字段最后都指定字段的别名,以面真实的字段名信息流失到客户端,从而加大黑客找到系统漏洞的可能。

     

    4.5.5格式约定

    1、  所有SQL关键字大写

    2、  使用良好的变量命名规范

    3、  保持良好的结构,包括空行、缩进和空格等。

    4、  块状的语句,一定要写上BEGIN…END

    5、  在每个存储过程的开头加上详细的注释:包括存储过程名称、参数说明、功能说明、返回数据集说明、以及作者和版权声明。

    6、  每个存储过程内的代码前后必须加上SET NOCOUNT ON 和SET NOCOUNT OFF。

    7、  存储过程格式的示例如下:

    CREATE PROCEDURE SP_User_update

    (

             @Options VarChar(100),

             @strUserName varchar(20),

             @strPwd varchar(50),

             @errno int = 0 OUTPUT,

             @errmsg varchar(255)=NULL OUTPUT

    )

     

    AS

    BEGIN

      IF @Options='UP1'

             BEGIN

             SET NOCOUNT ON

             /*以下是存储过程的代码*/

             SET NOCOUNT OFF

             END

             

     IF @Options='UP2'

             BEGIN

             SET NOCOUNT ON

             /*以下是存储过程的代码*/

             SET NOCOUNT OFF

             END

    END

     

     

    4.6视图命名

    一个数据库中的视图名不能重复

    视图名=VI(前缀)+[表名]..[表名]+[描述]

    4.7主键命名

    一个数据库中的主键名不能重复

    主键名=PK_(前缀)+[表名]

    例如:pk_Community

     

    4.8外键命名

    一个数据库中的外键名不能重复

    外键名=FK_(前缀)+[主表名]+[从表名]+[字段名]

    考虑这样一个关系,表Hotel,字段Id, Name, CityId。表City,字段Id,Name。因为一个城市可能有好多家酒店,所以是一个一对多的关系,City是主表(1方),Hotel是从表(多方)。在Hotel表中,CityId是做为外键使用。

    在实现外键的时候我们可以这样写:

    ALTER TABLE HotelInfo
    ADD CONSTRAINT FK_Hotel_City_Cityid  FOREIGN KEY (CityID) REFERENCES City(ID)

    4.9触发器命名

    1. 前缀(tr),描述了数据库对象的类型。
    2. 基本部分,描述触发器所加的表。
    3. 后缀(_I、_U、_D),显示了修改语句(Insert, Update及Delete)

    触发器名=TR_(前缀)+[表名]+[ _I、_U、_D]+[字段\描述]

    例如:TR _Communtiy_u_name(对表community的字段name进行更新)

     

    4.10 default约束

      使用格式如:DF_[表名]_[列名]

    例如:DF _Community_Age
     

    4.11CHECK 约束

    格式:CK_[表名]_[列名]

    例如:CK_Community_Number

    4.12UNIQUE约束

    格式:uq_[表名]_[列名]

    例如:uq_Community_Name

     

    4.13字段命名规范

    1、字段不使用任何前缀(表名代表了一个名称空间,字段前面再加前缀显得罗嗦)

    2、字典名也避免采用过于普遍过于简单的名称:例如,用户表中,用户名的字段为UserName比Name更好。

    3、布尔型的字段,以一些助动词开头,更加直接生动:如,用户是否有留言HasMessage,用户是否通过检查IsChecked等。

    4、字段名为英文短语、形容词+名词或助动词+动词时态的形式表示,大小写混合,遵循“见名知意”的原则。

    4.14 SQL语句规范

    1、不允许写SELECT * FROM ……,必须指明需要读取的具体字段。

    2、不允许在应用程序代码中直接写SQL语句访问数据库。

    3、避免在一行内写太长的SQL语句,在SQL关键字的地方将SQL语句分成多行会更加清晰。

      如:SELECT UserID,UserName,UserPwd FROM User_Login WHERE AreaID=20

    修改成:

    SELECT UserID,UserName,UserPwd

    FROM User_Login

    WHERE AreaID=20

    更加直观

    4、在一些块形式的SQL语句中,就算只有一行代码,也要加上BEGIN…END块。

       如:IF EXISTS(…)

                                SET @nVar = 100

    应该写成:

    IF EXISTS(…)

    BEGIN

               SET @nVar = 100

    END

    5、SQL批处理语句的空行和缩进与一般的结构化程序语言一致,应该保持良好的代码格式。

    6、所有的SQL关键字大写

     

    4.15游标使用约定

    1、  若无必要,不要使用游标

    2、  包含游标的存储过程,必须对性能进行认真测试。

     

    4.16索引命名规范

    对于数据库的维护建索引是很平常的事情,但是如果没有一个规范化的命名,我们对于一个表的诸多索引可能需要花上一段时间的了解。

    1. 如果表中存在主键默认情况下,表的聚集性索引也就是主键列,主键的命名前面已经有提到过,索引名也跟主键名一样,(Pk_表名)
    2. 对于表上的非聚集索引,建议使用(IX0_表名,IX1_表名)….,这样下去,这样也很清晰地表达了索引,对于很多命名文章上提到的需要详细表达出具体的列,我个人觉得没有必要,首先聚集索引经常涉及多列,很难罗列出所有列;还有影响美观

    当你执行SELECT  NAME  FROM SYS.COLUMNS 查询索引时,你根据NAME名很快就知道索引来自那张表,是否是非聚集索引,而不用根据OBJECTID列去跟对象表关联。

    4.17函数命名规范

    函数命名分两类:1.针对对象的函数,2.用作辅助功能操作的函数(不针对具体的数据库对象)

        1. 第一类命名:FN_+[User]+_+[对象名] 例如:FN_User_Student(对于Student进行操作函数)
        2. 第二类命名:FN_[具体函数解释] 例如:FN_Spit(对字段进行拆分函数)
    展开全文
  • MYSQL数据库设计规范与原则

    千次阅读 2018-12-15 08:58:04
    MYSQL数据库设计规范与原则 MYSQL数据库设计规范 1、数据库命名规范 采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成; 命名简洁明确(长度不能超过30个字符); 例如:user, stat, ...

    有远大抱负的人不可忽略眼前的工作!!!

    MYSQL数据库设计规范与原则

    MYSQL数据库设计规范
    
    1、数据库命名规范
        采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成;
        命名简洁明确(长度不能超过30个字符);
        例如:user, stat, log, 也可以wifi_user, wifi_stat, wifi_log给数据库加个前缀;
        除非是备份数据库可以加0-9的自然数:user_db_20151210;
         
    2、数据库表名命名规范
        采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成;
        命名简洁明确,多个单词用下划线'_'分隔;
        例如:user_login, user_profile, user_detail, user_role, user_role_relation,
            user_role_right, user_role_right_relation
        表前缀'user_'可以有效的把相同关系的表显示在一起;
         
    3、数据库表字段名命名规范
        采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成;
        命名简洁明确,多个单词用下划线'_'分隔;
        例如:user_login表字段 user_id, user_name, pass_word, eamil, tickit, status, mobile, add_time;
        每个表中必须有自增主键,add_time(默认系统时间)
        表与表之间的相关联字段名称要求尽可能的相同;
     
    4、数据库表字段类型规范
        用尽量少的存储空间来存数一个字段的数据;
        例如:能使用int就不要使用varchar、char,能用varchar(16)就不要使用varchar(256);
        IP地址最好使用int类型;
        固定长度的类型最好使用char,例如:邮编;
        能使用tinyint就不要使用smallint,int;
        最好给每个字段一个默认值,最好不能为null;
     
    5、数据库表索引规范
        命名简洁明确,例如:user_login表user_name字段的索引应为user_name_index唯一索引;
        为每个表创建一个主键索引;
        为每个表创建合理的索引;
        建立复合索引请慎重;
         
    6、简单熟悉数据库范式
        第一范式(1NF):字段值具有原子性,不能再分(所有关系型数据库系统都满足第一范式);
            例如:姓名字段,其中姓和名是一个整体,如果区分姓和名那么必须设立两个独立字段;
         
        第二范式(2NF):一个表必须有主键,即每行数据都能被唯一的区分;
            备注:必须先满足第一范式;
         
        第三范式(3NF):一个表中不能包涵其他相关表中非关键字段的信息,即数据表不能有沉余字段;
            备注:必须先满足第二范式;<br><br></pre>
    

    数据库的三范式:

    ①字段不可分。

    ②有主键,非主键字段依赖主键。

    ③非主键字段不能互相依赖。

             
            备注:往往我们在设计表中不能遵守第三范式,因为合理的沉余字段将会给我们减少join的查询;
                  例如:相册表中会添加图片的点击数字段,在相册图片表中也会添加图片的点击数字段;
    

    MYSQL数据库设计原则

    1、核心原则
        不在数据库做运算;
        cpu计算务必移至业务层;
        控制列数量(字段少而精,字段数建议在20以内);
        平衡范式与冗余(效率优先;往往牺牲范式)
        拒绝3B(拒绝大sql语句:big sql、拒绝大事物:big transaction、拒绝大批量:big batch);
    
    2、字段类原则
        用好数值类型(用合适的字段类型节约空间);
        字符转化为数字(能转化的最好转化,同样节约空间、提高查询性能);
        避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引无效);
        少用text类型(尽量使用varchar代替text字段);
     
    3、索引类原则
        合理使用索引(改善查询,减慢更新,索引一定不是越多越好);
        字符字段必须建前缀索引;
        不在索引做列运算;
        innodb主键推荐使用自增列(主键建立聚簇索引,主键不应该被修改,字符串不应该做主键)(理解Innodb的索引保存结构就知道了);
        不用外键(由程序保证约束);
     
    4、sql类原则
        sql语句尽可能简单(一条sql只能在一个cpu运算,大语句拆小语句,减少锁时间,一条大sql可以堵死整个库);
        简单的事务;
        避免使用trig/func(触发器、函数不用客户端程序取而代之);
        不用select *(消耗cpu,io,内存,带宽,这种程序不具有扩展性);
        OR改写为IN(or的效率是n级别);
        OR改写为UNION(mysql的索引合并很弱智);
            select id from t where phone = ’159′ or name = ‘john’;
            =&gt;
            select id from t where phone=’159′
            union
            select id from t where name=’jonh’
        避免负向%;
        慎用count(*);
        limit高效分页(limit越大,效率越低);
        使用union all替代union(union有去重开销);
        少用连接join;
        使用group by;
        请使用同类型比较;
        打散批量更新;
         
    5、性能分析工具
        show profile;
        mysqlsla;
        mysqldumpslow;
        explain;
        show slow log;
        show processlist;</pre>
    

    数据库的设计原则

    1. 原始单据与实体之间的关系 
      可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。 
    在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体。 
    这里的实体可以理解为基本表。明确这种对应关系后,对我们设计录入界面大有好处。 
    

    〖例1〗:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表、社会关系表、工作简历表。
           这就是“一张原始单证对应多个实体”的典型例子。

    1. 主键与外键
        一般而言,一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键
        (因为它无子孙), 但必须要有外键(因为它有父亲)。

    主键与外键的设计,在全局数据库的设计中,占有重要地位。当全局数据库的设计完成以后,有个美国数据库设计专
      家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核
      心(数据模型)的高度抽象思想。因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。

    1. 基本表的性质
        基本表与中间表、临时表不同,因为它具有如下四个特性:
         (1) 原子性。基本表中的字段是不可再分解的。
         (2) 原始性。基本表中的记录是原始数据(基础数据)的记录。
         (3) 演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。
         (4) 稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。
        理解基本表的性质后,在设计数据库时,就能将基本表与中间表、临时表区分开来。

    2. 范式标准
        基本表及其字段之间的关系, 应尽量满足第三范式。但是,满足第三范式的数据库设计,往往不是最好的设计。
        为了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余,达到以空间换时间的目的。

    〖例2〗:有一张存放商品的基本表,如表1所示。“金额”这个字段的存在,表明该表的设计不满足第三范式,
      因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。但是,增加“金额”这个冗余字段,
      可以提高查询统计的速度,这就是以空间换时间的作法。
      在Rose 2002中,规定列有两种类型:数据列和计算列。“金额”这样的列被称为“计算列”,而“单价”和
      “数量”这样的列被称为“数据列”。

    表1 商品表的表结构
      商品名称 商品型号 单价 数量 金额
      电视机 29吋 2,500 40 100,000
      
    5. 通俗地理解三个范式
      通俗地理解三个范式,对于数据库设计大有好处。在数据库设计中,为了更好地应用三个范式,就必须通俗地理解
      三个范式(通俗地理解是够用的理解,并不是最科学最准确的理解):
      第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解;
      第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性;
      第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。

    没有冗余的数据库设计可以做到。但是,没有冗余的数据库未必是最好的数据库,有时为了提高运行效率,就必须降
      低范式标准,适当保留冗余数据。具体做法是:在概念数据模型设计时遵守第三范式,降低范式标准的工作放到物理
      数据模型设计时考虑。降低范式就是增加字段,允许冗余。

    1. 要善于识别与正确处理多对多的关系
        若两个实体之间存在多对多的关系,则应消除这种关系。消除的办法是,在两者之间增加第三个实体。这样,原来一
        个多对多的关系,现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个
        实体,实质上是一个较复杂的关系,它对应一张基本表。一般来讲,数据库设计工具不能识别多对多的关系,但能处
        理多对多的关系。

    〖例3〗:在“图书馆信息系统”中,“图书”是一个实体,“读者”也是一个实体。这两个实体之间的关系,是一
      个典型的多对多关系:一本图书在不同时间可以被多个读者借阅,一个读者又可以借多本图书。为此,要在二者之
      间增加第三个实体,该实体取名为“借还书”,它的属性为:借还时间、借还标志(0表示借书,1表示还书),另外,
      它还应该有两个外键(“图书”的主键,“读者”的主键),使它能与“图书”和“读者”连接。

    注视:

    图书 1 和 该实体取名为“借还书” n
    读者 1 和 该实体取名为“借还书” n

    1. 主键PK的取值方法
         PK是供程序员使用的表间连接工具,可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义
        的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时,建议字段的个数不要太多,多了不但索引
        占用空间大,而且速度也慢。

    2. 正确认识数据冗余
        主键与外键在多表中的重复出现, 不属于数据冗余,这个概念必须清楚,事实上有许多人还不清楚。非键字段的重
        复出现, 才是数据冗余!而且是一种低级冗余,即重复性的冗余。高级冗余不是字段的重复出现,而是字段的派生出现。

    〖例4〗:商品中的“单价、数量、金额”三个字段,“金额”就是由“单价”乘以“数量”派生出来的,它就是冗余,
      而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性,因为同一数据,可
      能从不同时间、地点、角色上多次录入。因此,我们提倡高级冗余(派生性冗余),反对低级冗余(重复性冗余)。

    1. E–R图没有标准答案
        信息系统的E–R图没有标准答案,因为它的设计与画法不是惟一的,只要它覆盖了系统需求的业务范围和功能内容,
        就是可行的。反之要修改E–R图。尽管它没有惟一的标准答案,并不意味着可以随意设计。好的E—R图的标准是:
        结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。

    10 . 视图技术在数据库设计中很有用
      与基本表、代码表、中间表不同,视图是一种虚表,它依赖数据源的实表而存在。视图是供程序员使用数据库的
      一个窗口,是基表数据综合的一种形式, 是数据处理的一种方法,是用户数据保密的一种手段。为了进行复杂处理、
      提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表,
       在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。

    对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统,视图的作用更加重要。这些系统的基本表完
      成物理设计之后,立即在基本表上建立第一层视图,这层视图的个数和结构,与基本表的个数和结构是完全相同。
      并且规定,所有的程序员,一律只准在视图上操作。只有数据库管理员,带着多个人员共同掌握的“安全钥匙”,
      才能直接在基本表上操作。请读者想想:这是为什么?

    1. 中间表、报表和临时表
        中间表是存放统计数据的表,它是为数据仓库、输出报表或查询结果而设计的,有时它没有主键与外键(数据仓
        库除外)。临时表是程序员个人设计的,存放临时记录,为个人所用。基表和中间表由DBA维护,临时表由程序员
        自己用程序自动维护。

    2. 完整性约束表现在三个方面
        域的完整性:用Check来实现约束,在数据库设计工具中,对字段的取值范围进行定义时,有一个Check按钮,通
        过它定义字段的值城。
        参照完整性:用PK、FK、表级触发器来实现。
        用户定义完整性:它是一些业务规则,用存储过程和触发器来实现。

    3. 防止数据库设计打补丁的方法是“三少原则”
         (1) 一个数据库中表的个数越少越好。只有表的个数少了,才能说明系统的E–R图少而精,去掉了重复的多余的
          实体,形成了对客观世界的高度抽象,进行了系统的数据集成,防止了打补丁式的设计;

    (2) 一个表中组合主键的字段个数越少越好。因为主键的作用,一是建主键索引,二是做为子表的外键,所以组
        合主键的字段个数少了,不仅节省了运行时间,而且节省了索引存储空间;

    (3) 一个表中的字段个数越少越好。只有字段的个数少了,才能说明在系统中不存在数据重复,且很少有数据冗
        余,更重要的是督促读者学会“列变行”,这样就防止了将子表中的字段拉入到主表中去,在主表中留下许
        多空余的字段。所谓“列变行”,就是将主表中的一部分内容拉出去,另外单独建一个子表。这个方法很简
        单,有的人就是不习惯、不采纳、不执行。

    数据库设计的实用原则是:在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念,综合观点,
      不能孤立某一个原则。该原则是相对的,不是绝对的。“三多”原则肯定是错误的。试想:若覆盖系统同样的功
      能,一百个实体(共一千个属性) 的E–R图,肯定比二百个实体(共二千个属性) 的E–R图,要好得多。

    提倡“三少”原则,是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成
      为应用数据库,将应用数据库集成为主题数据库,将主题数据库集成为全局综合数据库。集成的程度越高,数据
      共享性就越强,信息孤岛现象就越少,整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数
      就会越少。

    提倡“三少”原则的目的,是防止读者利用打补丁技术,不断地对数据库进行增删改,使企业数据库变成了随意
      设计数据库表的“垃圾堆”,或数据库表的“大杂院”,最后造成数据库中的基本表、代码表、中间表、临时表
      杂乱无章,不计其数(即动态创表而增加表数量),导致企事业单位的信息系统无法维护而瘫痪。

    “三多”原则任何人都可以做到,该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的
      原则,它要求有较高的数据库设计技巧与艺术,不是任何人都能做到的,因为该原则是杜绝用“打补丁方法”
      设计数据库的理论依据。

    1. 提高数据库运行效率的办法
        在给定的系统硬件和系统软件条件下,提高数据库系统的运行效率的办法是:
         (1) 在数据库物理设计时,降低范式,增加冗余, 少用触发器, 多用存储过程。
         (2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条),复杂计算要先在数据库外面,以文件系统方
          式用C++语言计算处理完成之后,最后才入库追加到表中去。这是电信计费系统设计的经验。
         (3) 发现某个表的记录太多,例如超过一千万条,则要对该表进行水平分割。水平分割的做法是,以该表主键
          PK的某个值为界线,将该表的记录水平分割为两个表(即可以表维护 表行数过大 手动分割为两个 建个两表union的视图对程序透明)。若发现某个表的字段太多,例如超过八十个,则
          垂直分割该表,将原来的一个表分解为两个表。
         (4) 对数据库管理系统DBMS进行系统优化,即优化各种系统参数,如缓冲区个数。
         (5) 在使用面向数据的SQL语言进行程序设计时,尽量采取优化算法。
          总之,要提高数据库的运行效率,必须从数据库系统级优化、数据库设计级优化、程序实现级优化,这三
          个层次上同时下功夫。

    上述十四个技巧,是许多人在大量的数据库分析与设计实践中,逐步总结出来的。对于这些经验的运用,读者不能生帮硬套,死记硬背,而要消化理解,实事求是,灵活掌握。并逐步做到:在应用中发展,在发展中应用。

    转载自:http://www.javaeye.com/topic/281611

    展开全文
  • 4数据库字段设计规范 1最小模式 无符号省空间 过大的长度会消耗更多的内存 尽可能把所有列定义为not null 5数据库SQL开发规范6数据库操作行为规范
  • 就要忙着考虑数据库的设计,表、字段、索引、sql等等,而在项目比较大型的时候,团队开发中由于多人同时进行,那么尽早的进行设计规范是项目开发非常关键的一步,那么关于数据库设计规范有哪些呢,包括以下6项:  ...
  • 史上最强的MySQL数据库设计规范(互联网大厂都使用的2021年最新版本)
  • 数据库设计规范化的 5 个要求

    千次阅读 2016-03-29 14:26:50
    数据库设计规范化的 5 个要求
  • MySQL数据库设计规范

    千次阅读 2017-03-04 11:14:54
    [数据库命名规范] [表命名规范] [字段命名规范] 二、表设计原则 [职责分离原则] [在线处理与分析分离] [事务与日志分离] [历史可追溯] 一、命名规范 [数据库环境介绍] 通常来讲,各个互联网公司的数据库...
  • 数据库设计规范化的五个要求

    千次阅读 2013-10-29 15:01:35
    通常情况下,可以从两个方面来...为了达到数据库设计规范化的要求,一般来说,需要符合以下五个要求。  要求一:表中应该避免可为空的列。  虽然表中允许空列,但是,空字段是一种比较特殊的数据类型。数据库
  • mysql数据库设计学习---数据库设计规范化的五个要求 一:表中应该避免可为空的列; 二:表不应该有重复的值或者列; 三: 表中记录应该有一个唯一的标识符   在数据库表设计的时候,数据库管理员...
  • 数据库设计规范 每个公司都有自己数据库的规范 1数据库命名规范 1。1所有数据库对象名称必须使用小写字母并用下划线分割 1。2所有数据库对象名称禁止使用Mysql保留字关键字 1。3所有数据库对象名称要做到...
  • SQLServer数据库设计规范

    千次阅读 2008-07-28 10:47:00
    数据库设计规范(1)1 目的 规范数据库设计。 2 概述 从数据库的设计原则 设计文档几方面论述数据库设计的规范思想及命名规则。 3 数据库应用结构 根据对一般业务系统的分析,将数据库和程序系统统一进行整体...
  • 数据库设计规范(命名规范)

    千次阅读 2017-03-30 22:43:45
    规范数据库设计。  2 概述  从数据库的设计原则 设计文档几方面论述数据库设计规范思想及命名规则。  3 数据库应用结构  根据对一般业务系统的分析,将数据库和程序系统统一进行整体描述,展示数据库的  ...
  • 数据库设计规范-通用版

    万次阅读 2018-12-25 18:08:43
    1、不得使用数据库保留关键字,以及php/java等常用语言的保留关键字,或者可能成为关键字的单词作为完整命名。(对于一些疑似关键字的单词,可以在后面加一个下划线来避免,例如“key_”)。【附:MySQL保留关键字...
  • 一、 MYSQL数据库设计规范 1、 数据库命名规范 * 采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成; * 命名简洁明确(长度不能超过30个字符); * 例如:user, stat, log, 也可以wifi_user, ...
  • mysql数据库设计规范浅谈(一)

    万次阅读 多人点赞 2017-12-18 14:41:58
    《mysql设计规范》 数据结构设计:逻辑设计 –> 物理设计 实际工作中:逻辑设计 + 物理设计 物理设计:表名,字段名,字段类型 磁盘IO和操作系统类型,对mysql的性能是非常大的 一. 数据库命名规范 所有的数据库对象...
  • 数据库设计规范 V2.0

    2006-05-10 16:42:00
    数据库设计规范 V2.01 目的 规范数据库设计。2 概述 从数据库的设计原则 设计文档几方面论述数据库设计的规范思想及命名规则。3 数据库应用结构 根据对一般业务系统的分析,将数据库和程序系统统一进行整体...
  • (一) 建表规约 【强制】表达是与否概念的字段,必须使用is_xxx的...数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑。 正例:getter_admin,task_config,level3_name 反例:GetterAdmin,
  • 数据库设计规范、E-R图、模型图

    千次阅读 2019-07-09 10:17:59
    (1)数据库设计的优劣: 糟糕的数据库设计: ①数据冗余冗余、存储空间浪费。 ②数据更新和插入异常。 ③程序性能差。 良好的数据库设计 ①节省数据的存储空间。 ②能够保证数据的完整新。 ③方便进行...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 267,824
精华内容 107,129
关键字:

数据库设计规范