精华内容
下载资源
问答
  • 2018-08-20 16:28:54

    当前研发工作中经常出现因数据库表、数据库表字段格式不规则而影响开发进度的问题,在后续开发使用原来数据库表时,也会因为数据库表的可读性不够高,表字段规则不统一,造成数据查询,数据使用效率低的问题,所以有必要整理出一套合适的数据库表字段命名规范来解决优化这些问题。

    本文是一篇包含了数据库命名、数据库表命名、数据库表字段命名及SQL语言编码的规范文档,针对研发中易产生的问题和常见错误做了一个整理和修改,为日后涉及到数据库相关的研发工作做好准备。

     

     

    数据库规范化设计要求

    一、表中避免空列

    减少数据库处理记录的复杂性,

    1、空列数目少的时候,可以设置默认值。

    2、空列数目多的时候,可以设置单独一张表存储。

    二、表不应该有重复的值或列

    创建字典表

    三、唯一的标识某一条数据

    ID  

    如有必要添加 行号 进行排序显示管理

     

    四、数据库对象统一的前缀名

    t_department 

    五、尽量只存单一实体类型数据

    一个表中的字段不要太复杂 ,能分开的单独分开建表。

     

     


    数据库相关命名规范

     

    一、数据库命名规范

    采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔,一个项目一个数据库,多个项目慎用同一个数据库

     

    二、数据库表命名规范

    2.1数据表命名规范

    (1)采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔

    (2)全部小写命名,禁止出现大写

    (3)禁止使用数据库关键字,如:name,time ,datetime,password等(user ) 不然sql语句 写成 select * from [User]

    (4)表名称不应该取得太长(一般不超过三个英文单词)

    (5)表的名称一般使用名词或者动宾短语

    (6)用单数形式表示名称,例如,使用 employee,而不是 employees

    明细表的名称为:主表的名称+字符dtl(detail缩写)

    例如:采购定单的名称为:po_order,则采购定单的明细表为:po_orderdtl 

    (7)表必须填写描述信息(使用SQL语句建表时)

     

    2.2命名规范

    ①模块_+功能点  示例:alllive_log   alllive_category

    ②功能点  示例:live   message

    ③通用表  示例:all_user

     

    2.3待优化命名示例

    ①冗余:

    错误示例:yy_alllive_video_recomment    yy_alllive_open_close_log

    说明:去除项目名,简化表名长度,去”yy_”

     

    ②相同类别表命名存在差异,管理性差

    错误示例:yy_all_live_category    yy_alllive_comment_user

    说明:去除项目名,统一命名规则,均为”yy_alllive_”开头即可

     

    ③命名格式存在差异

    错误示例:yy_showfriend    yy_user_getpoints    yy_live_program_get

    说明:去除项目名,统一命名规则,动宾短语分离动宾逻辑顺序统一

     

    三、数据库字段命名规范

    3.1字段命名规范

    (1)采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线'_'组成,命名简洁明确,多个单词用下划线'_'分隔

    (2)全部小写命名,禁止出现大写

    (3)字段必须填写描述信息

    (4)禁止使用数据库关键字,如:name,time ,datetime password 等

    (5)字段名称一般采用名词或动宾短语

    (6)采用字段的名称必须是易于理解,一般不超过三个英文单词

    (7)在命名表的列时,不要重复表的名称

    例如,在名employe的表中避免使用名为employee_lastname的字段

    (8)不要在列的名称中包含数据类型

    (9)字段命名使用完整名称,禁止缩写

     

    3.2命名规范

    ①名词  示例:user_id    user_name    sex

    ②动宾短语  示例:is_friend   is_good

     

    3.3待优化命名示例

    ①大小写规则不统一

    错误示例:user_id    houseID

    说明:使用统一规则,修改为”user_id”,”house_id”

     

    ②加下划线规则不统一

    错误示例:username    userid    isfriend    isgood

    说明:使用下划线进行分类,提升可性,方便管理,修改为”user_name”,”user_id”,”is_friend”,”is_good”

     

    ③字段表示不明确

    错误示例:uid    pid

    说明:使用完整名称,提高可读性,修改为”user_id”,”person_id”

     

    3.4字段类型规范

    (1)所有字段在设计时,除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外,必须有默认值,字符型的默认值为一个空字符值串’’,数值型的默认值为数值0,逻辑型的默认值为数值0

    (2)系统中所有逻辑型中数值0表示为“假”,数值1表示为“真”,datetime、smalldatetime类型的字段没有默认值,必须为NULL

    (3)用尽量少的存储空间来存储一个字段的数据

    使用int就不要使用varchar、char,

    用varchar(16)就不要使varchar(256)

    IP地址使用int类型

    固定长度的类型最好使用char,例如:邮编(postcode)

    能使用tinyint就不要使用smallint,int

    最好给每个字段一个默认值,最好不能为null

    (4)用合适的字段类型节约空间

    字符转化为数字(能转化的最好转化,同样节约空间、提高查询性能)

    避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引无效)

    少用text类型(尽量使用varchar代替text字段)

     

    3.5数据库中每个字段的规范描述 

       (1)尽量遵守第三范式的标准(3NF) 

         表内的每一个值只能被表达一次 

         表内的每一行都应当被唯一的标示 

         表内不应该存储依赖于其他键的非键信息

    (2)如果字段事实上是与其它表的关键字相关联而未设计为外键引用,需建索引

    (3)如果字段与其它表的字段相关联,需建索引

    (4)如果字段需做模糊查询之外的条件查询,需建索引

    (5)除了主关键字允许建立簇索引外,其它字段所建索引必须为非簇索引

     

    四、SQL语言编码规范 

    4.1大小写规范 

    (1)所有关键字必须大写,如:INSERT、UPDATE、DELETE、SELECT及其子句,IF……ELSE、CASE、DECLARE等

    (2)所有函数及其参数中除用户变量以外的部分必须大写

    (3)在定义变量时用到的数据类型必须小写

     

    4.2注释 

    注释可以包含在批处理中,在触发器、存储过程中包含描述性注释将大大增加文本的可读性和可维护性,本规范建议: 

    (1)注释以英文为主,实际应用中,发现以中文注释的SQL语句版本在英文环境中不可用,为避免后续版本执行过程中发生某些异常错误,建议使用英文注释

    (2)注释尽可能详细、全面创建每一数据对象前,应具体描述该对象的功能和用途,传入参数的含义应该有所说明,如果取值范围确定,也应该一并说明,取值有特定含义的变量(如boolean类型变量),应给出每个值的含义

    (3)注释语法:单行注释、多行注释 

    单行注释:注释前有两个连字符(--)对变量、条件子句可以采用该类注释

    多行注释:符号之间的内容为注释内容,对某项完整的操作建议使用该类注释

    (4)注释简洁,同时应描述清晰

    (5)函数注释: 

    编写函数文本--如触发器、存储过程以及其他数据对象--时,必须为每个函数增加适当注释,该注释以多行注释为主,主要结构如下: 

    CREATE PROCEDURE sp_xxx 

     

     

     

     数据库表设计需要满足

    1、功能需求

    2、性能需求

    3、扩展性需求

     

     

    参考:

    数据库设计规范化的 5 个要求

    数据库表设计的几条准则

    数据库表结构设计浅谈

     

     

    数据库表及字段命名规范(一)

    更多相关内容
  • mysql比对两个数据库表结构的方法

    万次阅读 2017-12-24 13:02:20
    本文介绍mysql比对两个数据库表结构的方法,可以检查出两个数据库表的差异,并获取更新sql语句消除之间的差异。提供完整操作步骤与实例,方便大家比对数据库表结构时使用。

    在开发及调试的过程中,需要比对新旧代码的差异,我们可以使用git/svn等版本控制工具进行比对。而不同版本的数据库表结构也存在差异,我们同样需要比对差异及获取更新结构的sql语句。

    例如同一套代码,在开发环境正常,在测试环境出现问题,这时除了检查服务器设置,还需要比对开发环境与测试环境的数据库表结构是否存在差异。找到差异后需要更新测试环境数据库表结构直到开发与测试环境的数据库表结构一致。

    我们可以使用mysqldiff工具来实现比对数据库表结构及获取更新结构的sql语句。

    1.mysqldiff安装方法

    mysqldiff工具在mysql-utilities软件包中,而运行mysql-utilities需要安装依赖mysql-connector-python
     

    mysql-connector-python 安装

    下载地址:https://dev.mysql.com/downloads/connector/python/
     

    mysql-utilities 安装

    下载地址:https://downloads.mysql.com/archives/utilities/

    因本人使用的是mac系统,可以直接使用brew安装即可。

    brew install caskroom/cask/mysql-connector-python
    brew install caskroom/cask/mysql-utilities

    安装以后执行查看版本命令,如果能显示版本表示安装成功

    mysqldiff --version
    MySQL Utilities mysqldiff version 1.6.5 
    License type: GPLv2


    2.mysqldiff使用方法

    命令:

    mysqldiff --server1=root@host1 --server2=root@host2 --difftype=sql db1.table1:dbx.table3

     
    参数说明:

    --server1 指定数据库1
    --server2 指定数据库2

    比对可以针对单个数据库,仅指定server1选项可以比较同一个库中的不同表结构。
     

    --difftype 差异信息的显示方式

    unified (default)
    显示统一格式输出

    context
    显示上下文格式输出

    differ
    显示不同样式的格式输出

    sql
    显示SQL转换语句输出

    如果要获取sql转换语句,使用sql这种显示方式显示最适合。

    --character-set 指定字符集
    
    --changes-for 用于指定要转换的对象,也就是生成差异的方向,默认是server1
    
    --changes-for=server1 表示server1要转为server2的结构,server2为主。
    
    --changes-for=server2 表示server2要转为server1的结构,server1为主。
    
    --skip-table-options 忽略AUTO_INCREMENT, ENGINE, CHARSET的差异。
    
    --version 查看版本

    更多mysqldiff的参数使用方法可参考官方文档:
    https://dev.mysql.com/doc/mysql-utilities/1.5/en/mysqldiff.html

    3.实例

    创建测试数据库表及数据

    create database testa;
    create database testb;
    
    use testa;
    
    CREATE TABLE `tba` (
     `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
     `name` varchar(25) NOT NULL,
     `age` int(10) unsigned NOT NULL,
     `addtime` int(10) unsigned NOT NULL,
     PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=1001 DEFAULT CHARSET=utf8;
    
    insert into `tba`(name,age,addtime) values('fdipzone',18,1514089188);
    
    use testb;
    
    CREATE TABLE `tbb` (
     `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
     `name` varchar(20) NOT NULL,
     `age` int(10) NOT NULL,
     `addtime` int(10) NOT NULL,
     PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    
    insert into `tbb`(name,age,addtime) values('fdipzone',19,1514089188);

     
    执行差异比对,设置server1为主,server2要转为server1数据库表结构

    mysqldiff --server1=root@localhost --server2=root@localhost --changes-for=server2 --difftype=sql testa.tba:testb.tbb;
    # server1 on localhost: ... connected.
    # server2 on localhost: ... connected.
    # Comparing testa.tba to testb.tbb                                 [FAIL]
    # Transformation for --changes-for=server2:
    #
    
    ALTER TABLE `testb`.`tbb` 
      CHANGE COLUMN addtime addtime int(10) unsigned NOT NULL, 
      CHANGE COLUMN age age int(10) unsigned NOT NULL, 
      CHANGE COLUMN name name varchar(25) NOT NULL, 
    RENAME TO testa.tba 
    , AUTO_INCREMENT=1002;
    
    # Compare failed. One or more differences found.

     
    执行mysqldiff返回的更新sql语句

    mysql> ALTER TABLE `testb`.`tbb` 
        ->   CHANGE COLUMN addtime addtime int(10) unsigned NOT NULL, 
        ->   CHANGE COLUMN age age int(10) unsigned NOT NULL, 
        ->   CHANGE COLUMN name name varchar(25) NOT NULL;
    Query OK, 0 rows affected (0.03 sec)

     
    再次执行mysqldiff进行比对,结构没有差异,只有AUTO_INCREMENT存在差异

    mysqldiff --server1=root@localhost --server2=root@localhost --changes-for=server2 --difftype=sql testa.tba:testb.tbb;
    # server1 on localhost: ... connected.
    # server2 on localhost: ... connected.
    # Comparing testa.tba to testb.tbb                                 [FAIL]
    # Transformation for --changes-for=server2:
    #
    
    ALTER TABLE `testb`.`tbb` 
    RENAME TO testa.tba 
    , AUTO_INCREMENT=1002;
    
    # Compare failed. One or more differences found.

     
    设置忽略AUTO_INCREMENT再进行差异比对,比对通过

    mysqldiff --server1=root@localhost --server2=root@localhost --changes-for=server2 --skip-table-options --difftype=sql testa.tba:testb.tbb;
    # server1 on localhost: ... connected.
    # server2 on localhost: ... connected.
    # Comparing testa.tba to testb.tbb                                 [PASS]
    # Success. All objects are the same.
    展开全文
  • 数据库表结构设计方法及原则

    千次阅读 2020-12-01 22:30:43
    在目前的企业信息系统中,数据库还是最佳的数据存储方式,虽然已经有很多的书籍在指导我们进行数据库设计,但应该那种方式是设计数据库表结构的最好方法、设计时应遵从什么样的原则、四范式如何能够用一种方式...

    在目前的企业信息系统中,数据库还是最佳的数据存储方式,虽然已经有很多的书籍在指导我们进行数据库设计,但应该那种方式是设计数据库的表结构的最好方法、设计时应遵从什么样的原则、四个范式如何能够用一种方式达到顺畅的应用等是我一直在思考和总结的问题,下文是我针对这几个问题根据自己的设计经历准备总结的一篇文章的提纲,欢迎大家一块进行探讨,集思广益。其中提到了领域建模的概念,但未作详细解释,希望以后能够有时间我们针对这个命题进行深入探讨。

    1)不应该针对整个系统进行数据库设计,而应该根据系统架构中的组件划分,针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之间的关联应尽可能减少,如果不同组件间的表需要外键关联也尽量不要创建外键关联,而只是记录关联表的一个主键,确保组件对应的表之间的独立性,为系统或表结构的重构提供可能性。

    2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计,首先分析系统业务,根据职责定义对象。对象要符合封装的特性,确保与职责相关的数据项被定义在一个对象之内,这些数据项能够完整描述该职责,不会出现职责描述缺失。并且一个对象有且只有一项职责,如果一个对象要负责两个或两个以上的职责,应进行分拆。

    3)根据建立的领域模型进行数据库表的映射,此时应参考数据库设计第二范式:一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性,也可以是多个属性的集合,不论那种方式,都应确保关键字能够保证唯一性。在确定关键字时,应保证关键字不会参与业务且不会出现更新异常,这时,最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。

    4)由于第一点所述的领域模型驱动的方式设计数据库表结构,领域模型中的每一个对象只有一项职责,所以对象中的数据项不存在传递依赖,所以,这种思路的数据库表结构设计从一开始即满足第三范式:一个表应满足第二范式,且属性间不存在传递依赖。

    5)同样,由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系,所以在领域模型中的对象存在主对象和从对象之分,从对象是从1-N或N-N的角度进一步分析主对象的业务逻辑,所以从对象及对象关系映射的表及表关联关系不存在删除和插入异常。

    6)在映射后得出的数据库表结构中,应再根据第四范式进行进一步修改,确保不存在多值依赖。这时,应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖,则证明领域模型中的对象具有至少两个以上的职责,应根据第一条进行设计修正。第四范式:一个表如果满足BCNF,不应存在多值依赖。

    7)在经过分析后确认所有的表都满足二、三、四范式的情况下,表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且,我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的,只是一个存储介质,所以,表和表之间也不应用强关联来表述业务(数据间的一致性),这一职责应由系统的逻辑层来保证,这种方式也确保了系统对于不正确数据(脏数据)的兼容性。当然,从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据,单从另一个角度来说,脏数据的产生在一定程度上也是不可避免的,我们也要保证系统对这种情况的容错性。这是一个折中的方案。

    8)应针对所有表的主键和外键建立索引,有针对性的(针对一些大数据量和常用检索方式)建立组合属性的索引,提高检索效率。虽然建立索引会消耗部分系统资源,但比较起在检索时搜索整张表中的数据尤其时表中的数据量较大时所带来的性能影响,以及无索引时的排序操作所带来的性能影响,这种方式仍然是值得提倡的。

    9)尽量少采用存储过程,目前已经有很多技术可以替代存储过程的功能如“对象/关系映射”等,将数据一致性的保证放在数据库中,无论对于版本控制、开发和部署、以及数据库的迁移都会带来很大的影响。但不可否认,存储过程具有性能上的优势,所以,当系统可使用的硬件不会得到提升而性能又是非常重要的质量属性时,可经过平衡考虑选用存储过程。

    10)当处理表间的关联约束所付出的代价(常常是使用性上的代价)超过了保证不会出现修改、删除、更改异常所付出的代价,并且数据冗余也不是主要的问题时,表设计可以不符合四个范式。四个范式确保了不会出现异常,但也可能由此导致过于纯洁的设计,使得表结构难于使用,所以在设计时需要进行综合判断,但首先确保符合四个范式,然后再进行精化修正是刚刚进入数据库设计领域时可以采用的最好办法。

    11)设计出的表要具有较好的使用性,主要体现在查询时是否需要关联多张表且还需使用复杂的SQL技巧。

    12)设计出的表要尽可能减少数据冗余,确保数据的准确性,有效的控制冗余有助于提高数据库的性能。

    数据库设计原则

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    上一篇:Oracle数据库访问性能优化

    下一篇:Oracle行链接(Row chaining) 与行迁移(Row Migration)

    展开全文
  • a:要修改的对象,指的是源数据库表结构和目标数据库表结构相同,例如,增加栏位,或者删除栏位 b:要增加的对象,指的是源数据库存在的对象,目标数据库中不存在,比如,有新增 c:...

    1,Navicat Premium 打开后,连接需要对比的数据库

    2.点击工具---结构同步

    3.选择需要同步或比对的源数据库和目标数据库,选择完成后,点击右下角“比对”按钮,

    4.查看比对结果

    a:要修改的对象,指的是源数据库中表结构和目标数据库中表结构不相同,例如,增加栏位,或者删除栏位

    b:要增加的对象,指的是源数据库中存在的对象,目标数据库中不存在,比如,有新增表

    c:要删除的对象,指的是源数据库中不存在,目标数据库中存在,比如,删除表

    5,点击上图右下角“部署”按钮,查看部署脚本

    6,确认无误后,点击运行,实现数据结构同步

    展开全文
  • 数据库表结构设计

    千次阅读 2019-04-08 21:20:30
    在进行数据库表结构设计的实操之前,应当好好了解一下数据库表结构设计的几关键的问题: 为什么要学习数据库表结构设计 在实际的数据库开发中,需要将大量的结构化数据汇总到数据库表中,这时候不能鲁莽的开始...
  • 表结构不一样(这种情况下得指定列名)注意:插入时查询的字段的别称,要与插入表字段名称相同 insert into 1 (列名1,列名2,列名3) select 列1,列2,列3 from 23、快速复制或备份  CREATE TABLE `user_...
  • MySQL数据库表结构的设计

    万次阅读 多人点赞 2019-05-28 13:51:56
    MySQL数据库表结构的设计。四大范式。表结构的设计是数据库优化中至关重要的环节,需要认真谨慎对待,在遵守四大范式的前提下,充分考虑业务未来的可扩展性,适应未来业务变化,促进系统更加健康健壮。
  • 数据库表的存储结构-SQL Server

    万次阅读 2016-07-05 10:48:09
    SQL Server数据库的存储结构
  • 数据库表结构)设计技巧及注意事项

    万次阅读 多人点赞 2017-12-01 16:51:39
    当您在决定开发一个数据库管理项目时,最先着手的工作就应是数据库表结构的设计了。可以这么说,表结构的设计是开发数据库管理项目的基石,一糟糕的表结构设计,可能会严重延误您的项目开发周期,使您大量的劳动...
  • oracle合并结构相同

    千次阅读 2015-05-10 16:58:12
    insert into c select * from a union select * from b; 使用insert into 就可以了,注意union (all) 前后的select 列表中的字段数量与类型须保持一致。
  • 在项目维护和开发中,经常需要知道两个数据库之间有哪些差异,如两个数据库中数据有什么不同(的名称,数量),相同的表字段是否相同(字段数目,约束,字段类型,大小等),有各种数据库管理工具可以实现这一点,...
  • 【产生背景】 我们在实际开发的过程中,通常会有开发环境、测试环境、生产...当我们想知道两个数据库的有哪些变化时候,如果每张,每个字段的去比较,当在变化很大的时候,这将会是一个很不友好的体验,不但耗时耗
  • 数据库表结构设计方法及原则(li)

    千次阅读 2018-06-28 00:41:42
    https://www.cnblogs.com/RunForLove/p/5693986.html数据库...要想设计一个结构合理的关系型数据库,必须满足一定的范式。 在实际开发中最为常见的设计范式有三个:第一范式是最基本的范式。如果数据库表中的所有字...
  • 这几天因为工作需要对数据库的数据进行同步,顺便研究了一下从2不同的数据库中同步表结构相同表的数据 网上的一些资料好像都做得很复杂 自己整理写了一简单的(不考虑性能)同步工具,分享一下表同步过程...
  • MySQL创建数据库和创建数据

    万次阅读 多人点赞 2019-10-20 23:44:40
    MySQL 创建数据库和创建数据 MySQL 是最常用的数据库,在...数据库在操作时,需要使用专门的数据库操作规则和语法,这语法就是SQL(Structured Query Language) 结构化查询语言。 SQL 的主要功能是和数据库...
  • 前言 最近这需求是 php 接收前端数据,然后将数据存入数据库中,但相同记录不能存入。 查了查百度,都把简单的事情复杂化了,竟然还有先查询数据再判断插入的方式(大拇指),...(1)一个数据库表结构如下: ...
  • 数据库——数据库结构设计

    千次阅读 2020-03-08 22:21:25
    与抽象,形成一独立于DBMS 的概念模型 数据库概念设计的目标 1 定义与描述应用领域设计的数据范围 2 获取信息模型 3 描述数据的属性特征 4 描述数据之间的关系 5 定义和描述数据的约束 6 说明数据的安全性要求 7 ...
  • 在任意一个表建立外键,去关联另外一个表的主键 SQL演示 -- 创建db5数据库 CREATE DATABASE db5; -- 使用db5数据库 USE db5; -- 创建person CREATE TABLE person( id INT PRIMARY KEY AUTO_INCREMENT,
  • 我们可以利用这两个工具的优势来生成所需的脚本,以创建要与其对象一起复制的,并按照以下步骤将数据从源复制到目标: ApexSQL Diff tool ApexSQL Diff工具 From the Data sources tab of the New project ...
  • 数据库操作命令 操作命令 修改表结构命令 数据操作命令 数据查询操作命令
  • mysql 数据库表结构设计与规范

    千次阅读 2017-06-06 15:00:16
    mysql 数据库表结构设计与规范DDL(data difinition language)就是数据定义语言。1.sql语句的界定符[code]– 默认情况下” ; ” 代表sql语句的结束 delimiter 新的界定符 – 修改 // 为界定符 delimiter //2.创建...
  • 首先从A库导出产品的数据模型到Excel中,导出完成时记录导出产品条目以及产品结构到B库的Model和Partstr中。然后就是每隔一段固定时间系统自动进行数据比对(系统自动执行比对服务详见...
  • 数据库表的设计流程和思考方向

    千次阅读 2020-05-10 09:52:33
    按照规范设计的方法,考虑数据库及其应用系统开发全过程,将数据库设计分为以下6阶段 1.需求分析 2.概念结构设计 3.逻辑结构设计 4.物理结构设计 5.数据库实施 6.数据库的运行和维护   数据库设计通常分为6...
  • 数据库表设计

    万次阅读 2018-01-20 02:38:06
    以该主键PK的某个值为界线,将该的记录水平分割为两个表。若发现某个的字段太多,例如超过 八十个,则垂直分割该,将原来的一个分解为两个表。 逻辑数据库设计 - 单纯的树(递归...
  • 数据库的合并,sql语言进行数据库合并,以及复制内容的具体语言,结构
  • 数据库的存储结构

    千次阅读 2020-10-24 22:49:40
    快速回顾一遍数据库存储结构:一页可以存储多行记录(Row) ,先是空间(Tablespace),空间包含段(segement),还存在区(Extent),其关系如下图所示: 段(Segment)段里面有多区,区在文件系统是一...
  • 设计关系型数据库时,需要给添加一ID字段(自增字段,或者uuid字段)和一version字段(数值类型)。ID字段作为物理主键,用于保证记录的不可重复性和用作外键关联。 version字段用于实现乐观锁,提供比...
  • 数据库系统结构 一、数据库系统的三级模式结构:外模式、模式、内模式 名称 功能 定义和描述语言 模式(Schema)也称概念模式或逻辑模式 它是数据库总的框架,是对数据库中全体数据的逻辑结构和特性的描述,...
  • SQL语句修改数据库表结构

    万次阅读 2013-03-13 19:54:37
    一、查看表结构  1、查看的基本结构语句:  DESCRIBE `DEPT`;  2、查看详细结构语句:  SHOW CREATE TABLE `DEPT`; 二、对表的操作 增加 CREATE TABLE `dept` (  `id` int(10) unsigned NOT NULL AUTO_...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 677,516
精华内容 271,006
关键字:

存在两个结构相同的数据库表