精华内容
下载资源
问答
  • 前两种关系只需要本身就能表达清楚,然而多对多需要第三张中间才能表达清楚多对多的关系。 中间在一般情况下是由三个字段组成: 1、中间本身自增主键 2、两张各自主键。 这时候命名就成为了一个...

    在关系型数据库中,除了有一对一,一对多外,还有多对多的关系。前两种关系只需要表本身就能表达清楚,然而多对多需要第三张中间表才能表达清楚多对多的关系。

    中间表在一般情况下是由三个字段组成:

                    1、中间表本身的自增主键

                    2、两张表各自的主键。

             这时候命名就成为了一个问题,而采用双下划线就能解决这个问题。

    比如:角色组表(group)和菜单表(rule),一个角色可以有多个菜单,一个菜单也可以多个角色。那么他们的中间表就是group__rule

    展开全文
  • 前两个关系都只需要两个本身就能表达清楚他们之间的关系,而多对多关系则需要第三张中间来表达清楚两张之间的关系. 中间在一般情况下是由三个字段组成: 1、中间本身自增主键 2、两张各自主键。 .....

             在关系数据库中,除了一对一,一对多外,还有一个多对多关系.前两个关系都只需要两个表本身就能表达清楚他们之间的关系,而多对多关系则需要第三张中间表来表达清楚两张表之间的关系.

            中间表在一般情况下是由三个字段组成:

                    1、中间表本身的自增主键

                    2、两张表各自的主键。

             这时候命名就成为了一个问题,而采用双下划线就能解决这个问题。

    举个例子:一本书有多个作者,一个作者会写多本书。

    这就是典型的多对多的关系。假设书和作者的表名分别为:shu,zuo_zhe。那么他们的中间表的名称就是shu__zuo_zhe。这样的表示方法完全通用,适用于任何情况的中间表的命名,至于到底是shu__zuo_zhe,还是zuo_zhe__shu。这个区别不大我个人倾向于shu__zuo_zhe,因为常用或者更主要的表名字在前,更方便记忆。


    (注:主要内容转载自他人,但是格式以及部分内容为我后补充的。)

    转载于:https://www.cnblogs.com/haxianhe/p/9271067.html

    展开全文
  • 有User类,Role类,是多对多的关系 ef5生成的关系表是RoleUsers ef6生成的关系表是UserRoles 同样的代码生成的关系表的表名却不同,关系表的表名可不可以自己定义呢?
  • 1.数据库设计14规则 1. 原始单据与实体之间的关系   可以是一对一、一对多、多对多的关系。...这里实体可以理解为基本。明确这种对应关系后,对我们设计录入界面大有好处。   〖例1〗:一份员工履

    1.数据库设计14规则

    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表示还书),另外, 
      它还应该有两个外键(“图书”的主键,“读者”的主键),使它能与“图书”和“读者”连接。 


    注视:


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


    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的某个值为界线,将该表的记录水平分割为两个表(即可以表维护 表行数过大 手动分割为两个  建个两表union的视图对程序透明)。若发现某个表的字段太多,例如超过八十个,则 
        垂直分割该表,将原来的一个表分解为两个表。 
       (4) 对数据库管理系统DBMS进行系统优化,即优化各种系统参数,如缓冲区个数。 
       (5) 在使用面向数据的SQL语言进行程序设计时,尽量采取优化算法。 
        总之,要提高数据库的运行效率,必须从数据库系统级优化、数据库设计级优化、程序实现级优化,

    2.表、字段命名规则

    .数据库表命名规范:
    (1)表名前应该加上前缀,表的前缀一个用系统或模块的英文名称缩写,前缀全部大写或首字母大写,表名中包含的单词首字母大写。
    (2)数据库表名应该有意义,并且易于理解,最好使用可以表达功能的英文单词或缩写,如果用英文单词表示,建议使用完整的英文单词。
    (3)表名不可以太长,最好不要超过3个英文单词长度(22个字母)。
    (4)在数据库表命名时应该用英文单词的单数形式,如员工表命名:应该为Employee而不是Employees .
    (5)如果是后台表命名时应该在表名基础上加上后缀_b(back 首字母 )
    (6)在表创建完成前,应该为表添加表的注释。

    2.表字段命名规范:
    (1)数据库表字段应该是有意义而且易于理解的,最好是能够表达字段含义的英文字母
    (有人认为如果用英文单词作为字段,因为翻译工具不同,而字段不统一建议使用汉语拼音首字母缩写;有人认为用汉语拼音缩写看起来不直观,老半天也不知道到底这个字段是干什么的)
    (2)系统中所有属于内码,即仅用于标识唯一性和程序内部用到的标识性字段,字段名称建议取为 ID ,采用类型为整型或长整型.
    (3)系统中属于是业务内的编号字段,代表一定业务信息,建议字段命名为code , 如工作单编号wf_code .
    (4) 不要在数据库表字段(列名)中包含数据类型,如:datetime
    (5)不要在数据库表字段(列名)命名时重复表名,可以使用表名首字母(不包含数据库表名前缀)
    注意:不要在数据库表字段(列名)命名时不建议使用数据库关键字,如:name,time ,datetime password 等

    3.表设计规范:
    (1)所有字段在设计时,除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary、varbinary外,必须有默认值。字符型的默认值为一个空字符值串’’;数值型的默认值为数值0;逻辑型的默认值为数值0;
    其中:系统中所有逻辑型中数值0表示为“假”;数值1表示为“真”。
    datetime、smalldatetime类型的字段没有默认值,必须为NULL。
    (2)当字段定义为字符串形时建议使用varchar而不用nvarchar。
    注:在MySQL5.0以上的版本中,varchar数据类型的长度支持到了65535,也就是说可以存放65532个字节的数据,起始位和结束位占去了3个字节。
    (3)建议在大多数表中(如工作单),应都有以下字段:
    字段名说明类型默认值
    CreatorID创建者int默认值为0
    CreatedTime创建时间Datetime默认值为NULL
    (4)字段的描述
    a.字段必须填写描述信息(注释)
    b.尽量遵守第三范式的标准(3NF)
    表内的每一个值只能被表达一次(列名不重复)
    表内的每一行都应当被唯一的标示(标识唯一性,如自动增长主键)
    表内不应该存储依赖于其他键的非键信息
    (5)加索引规则
    a.表建好后数据库自动为表生成一个索引(为自动增长的列生成唯一索引),如果在对这列添加索引,数据库会给一个警告,内容大概是,已经为这列添加了索引,建议修改索引名称和自动增长列名保持一致,为了方便使用。
    b.如果在添加索引时,建议索引名称和数据库列名保持一致,为了方便使用
    c.如果字段事实上是与其它表的关键字相关联而未设计为外键引用,需建索引。
    d.如果字段与其它表的字段相关联,需建索引。
    e.如果字段需做模糊查询之外的条件查询,需建索引。
    f.除了主关键字允许建立簇索引外,其它字段所建索引必须为非簇索引。

    4.存储过程命名规范
    (1)存贮过程的命名请遵循以下命名规范:USP_ + 系统模块缩写(与表前缀类似)+ + 功能标识 + 代表存贮过程操作的主要表名(不带前缀)或功能的英文单词或英文单词缩写。
    如果一个存贮过程只对一个表进行操作,建议存贮过程的名称就用存贮过程所操作的表的表名(不带前缀)。这样有利于根据表名找到相应的存贮过程。例如:
    用于新增的存贮过程USP_MESSAGE_Add_Model
    用于修改的存贮过程USP
    MESSAGE_Upt_Model
    用于删除的存贮过程USP_ MESSAGE_Del_ Modele
    注:USP是user stored procedure缩写
    5.存储过程设计规范
    在存贮过程中必须说明以下内容:
    (1)目的:说明此存贮过程的作用。
    (2)作者:首次创建此存贮过程的人的姓名。在此请使用中文全名,不允许使用英文简称。
    (3)创建日期:创建存贮过程时的日期。
    (4)修改记录:
    修改记录需包含修改顺序号、修改者、修改日期、修改原因,修改时不能直接在原来的代码上修改,也不能删除原来的代码,只能先将原来的代码注释掉,再重新增加正确的代码。修改顺序号的形式为:log1,log2,log3。。。,根据修改次数顺序增加,同时在注释掉的原来的代码块和新增的正确代码块前后注明修改顺序号。
    (5)对存贮过程各参数及变量的中文注解。
    建议:在数据库中创建一个文本文件保存创建脚本

    6.视图命名规范
    视图的命名请遵循以下命名规范:UV + 系统模块缩写(与表前缀类似)+ + 功能标识 + 代表视图查询的主要表名(不带前缀)或功能的英文单词或英文单词缩写。
    如果一个视图只对一个表进行查询,建议视图的名称就用视图所查询的表的表名(不带前缀)。这样有利于根据表名找到相应的视图。
    注:UV是userView缩写
    7.视图设计规范
    在视图中必须说明以下内容:
    (1)目的:说明此视图的作用。
    (2)创建者:首次创建此视图的人的姓名。在此请使用中文全名,不允许使用英文简称。
    (3)修改者、修改日期、修改原因:如果有人对此视图进行了修改,则必须在此视图的前面加注修改者姓名、修改日期及修改原因。
    (4)对视图各参数及变量的中文注解
    建议:在数据库中创建一个文本文件保存创建脚本
    8.触发器命名规范
    Insert触发器加'_i',Delete触发器加'_d',Update触发器加'_u'
    9.触发器设计规范
    在视图中必须说明以下内容:
    (1)目的:说明此触发器的作用。
    (2)创建者:首次创建此触发器的人的姓名。在此请使用中文全名,不允许使用英文简称。
    (3)修改者、修改日期、修改原因:如果有人对此触发器进行了修改,则必须在此触发器的前面加注修改者姓名、修改日期及修改原因。
    (4)对触发器各参数及变量的中文注解
    建议:在数据库中创建一个文本文件保存创建脚本


    3.mysql索引建立原则

    数据库索引的设计原则:

    为了使索引的使用效率更高,在创建索引时,必须考虑在哪些字段上创建索引和创建什么类型的索引。
    那么索引设计原则又是怎样的?
    1.选择唯一性索引
    唯一性索引的值是唯一的,可以更快速的通过该索引来确定某条记录。
    例如,学生表中学号是具有唯一性的字段。为该字段建立唯一性索引可以很快的确定某个学生的信息。
    如果使用姓名的话,可能存在同名现象,从而降低查询速度。

    2.为经常需要排序、分组和联合操作的字段建立索引
    经常需要ORDER BY、GROUP BY、DISTINCT和UNION等操作的字段,排序操作会浪费很多时间。
    如果为其建立索引,可以有效地避免排序操作。

    3.为常作为查询条件的字段建立索引
    如果某个字段经常用来做查询条件,那么该字段的查询速度会影响整个表的查询速度。因此,
    为这样的字段建立索引,可以提高整个表的查询速度。

    4.限制索引的数目
    索引的数目不是越多越好。每个索引都需要占用磁盘空间,索引越多,需要的磁盘空间就越大。
    修改表时,对索引的重构和更新很麻烦。越多的索引,会使更新表变得很浪费时间。

    5.尽量使用数据量少的索引
    如果索引的值很长,那么查询的速度会受到影响。例如,对一个CHAR(100)类型的字段进行全文
    检索需要的时间肯定要比对CHAR(10)类型的字段需要的时间要多。

    6.尽量使用前缀来索引
    如果索引字段的值很长,最好使用值的前缀来索引。例如,TEXT和BLOG类型的字段,进行全文检索
    会很浪费时间。如果只检索字段的前面的若干个字符,这样可以提高检索速度。

    7.删除不再使用或者很少使用的索引
    表中的数据被大量更新,或者数据的使用方式被改变后,原有的一些索引可能不再需要。数据库管理
    员应当定期找出这些索引,将它们删除,从而减少索引对更新操作的影响。

     
    8.小表不应建立索引;包含大量的列并且不需要搜索非空值的时候可以考虑不建索引
     

    mysql索引相关小常识:

    一,经常被用来过滤记录的字段。

    1. primary key 字段, 系统自动创建主键的索引;
    2. unique key 字段,系统自动创建对应的索引;

    3. foreign key 约束所定义的作为外键的字段;

    4. 在查询中用来连接表的字段;

    5. 经常用来作为排序(order by 的字段)基准的字段;


    二. 索引会占用磁盘空间,创建不必要的索引只会形成浪费.

    三. 索引的创建必须考虑数据的操作方式。

    1.内容很少变动,经常被查询,为它多创建几个索引無所谓;

    2.经常性,例行性变动的表而言,则需要谨慎地创建确实必要的索引;


    四. primary key 和 unique key的区别
    1. 作为Primary Key的域/域组不能为null。而Unique Key可以。
    2. 在一个表中只能有一个Primary Key,而多个Unique Key可以同时存在。
    更大的区别在逻辑设计上, Primary Key一般在逻辑设计中用作记录标识,这也是设置
    Primary Key的本来用意, 而Unique Key只是为了保证域/域组的唯一性。


    五.复合索引和单一索引

      复合索引是指多字段联合索引,查询时经常需要这几个字段组合一起为条件再查询 
      唯一索引主要是用主键ID索引,存储结构顺序与物理结构一致

    如:create  index  idx  on  tbl(a,b)  
     先按a排序, a相同的按b排序,所以当你查a或ab的时候, 
    能够利用到这个索引.但当你只查b的时候,索引对你的帮助不大.可能可以跳跃查找.


     
    添加和删除索引的情况:
     
    1、表的主键、外键必须有索引;

    2、数据量超过300w的表应该有索引;

    3、经常与其他表进行连接的表,在连接字段上应该建立索引;

    4、经常出现在Where子句中的字段,特别是大表的字段,应该建立索引;

    5、索引应该建在选择性高的字段上;

    6、索引应该建在小字段上,对于大的文本字段甚至超长字段,不要建索引;

    7、复合索引的建立需要进行仔细分析;尽量考虑用单字段索引代替:

       A、正确选择复合索引中的主列字段,一般是选择性较好的字段;

       B、复合索引的几个字段是否经常同时以AND方式出现在Where子句中?单字段查询是否极少甚至没有?如果是,则可以建立复合索引;否则考虑单字段索引;

       C、如果复合索引中包含的字段经常单独出现在Where子句中,则分解为多个单字段索引;

       D、如果复合索引所包含的字段超过3个,那么仔细考虑其必要性,考虑减少复合的字段;

       E、如果既有单字段索引,又有这几个字段上的复合索引,一般可以删除复合索引;

    8、频繁进行数据操作的表,不要建立太多的索引;

    9、删除无用的索引,避免对执行计划造成负面影响;


    展开全文
  • 多对多关系的中间表命名

    千次阅读 2019-09-24 11:00:09
    在网上看一些,以及我个人使用方法,总结一个规则:table1_table2 转载于:https://www.cnblogs.com/Jerrycjc/p/7146971.html

    在网上看一些,以及我个人使用的方法,总结一个规则:table1_table2

    转载于:https://www.cnblogs.com/Jerrycjc/p/7146971.html

    展开全文
  • Entity:实体类,该命名抽象要求与数据库中的表结构要有对象关系。 Pojo:无意义实体数据抽象,一般是不具备业务逻辑在其中。 Model:主要是mvc中,扮演内部数据处理、转换角色。 Dto:Data Transfer ...
  • DJ 代表电子接插件 7 代表插片式 02 代表2个孔 1 代表设计序号 ...DJ系列接插件和AMP系列对照 0.6 系列 DJ7031-0.6-21 1-967642-1(AMP 安普号 ) DJ621-0.6S-1 928999-1(AMP 安普号 ) DJ621-0.6A-1
  • 探讨数据仓库模型命名规则

    千次阅读 2009-10-27 05:14:00
    http://www.dwway.com/bbs/viewthread.php?tid=23689探讨数据仓库模型命名规则在以前做联通经营分析项目中,对命名规范问题虽也考虑,可虽着项目深入,就有不遵守规则了,数据库中表名,字段名五花八门,...
  • 一、简述  mybatis驼峰式命名...使用好处:省去mapper.xml文件中繁琐编写表字段列表与实体类属性映射关系,即resultMap。 示例: <resultMap id ="UserInfoMap" type="com.example.mybaitsxml.dao...
  • 在页面中要利用DataSet的主副表关系需要注意一点,就是两张表的表名,如果你把dataset分别对应两个列表的时候,如果表名不是按照下面的规则进行命名的话,副表会显示所有的记录,副表的表名一定要是“主表.”开头,...
  • 目录方法Tables和ImageButtons的ID的命名规则 网页上Table的字段长度的估计主要程序事件过程 应用实例方法 :对DataSet中的每一张,如果有子,将这张表的字段名行和每一纪录行在网页上都显示为只有一行的Table,...
  • C语言规则

    2019-02-22 09:36:21
    C语言规则语言规则—基础语言规则—避免使用语言规则—依赖关系语言规则—类型语言规则—变量语言规则—指针语言规则—表达式语言规则—函数语言规则—内存及资源语言规则—源文件引用头文件顺序头文件多重引用...
  • 数据库设计规范(命名规范)

    千次阅读 2017-03-30 22:43:45
    从数据库设计原则 设计文档几方面论述数据库设计规范思想及命名规则。  3 数据库应用结构  根据对一般业务系统分析,将数据库和程序系统统一进行整体描述,展示数据库  之间以及与程序模块间的关系...
  • 数据库表的对应关系 1、一对一 #关联字段写在那张表都可以 PS:只要写OneToOneField就会自动加一个id 2、一对多 #关系确立,关联...PS:自动 创建的第三章表命名规则就是app_表名_表名 创建表的对应关系 ''...
  • 使用好处:省去mapper.xml文件中繁琐编写表字段列表与实体类属性映射关系,即resultMap。 1、方式一  直接application.yml文件中配置开启 #mybatis配置 mybatis: typeAliasesPackage: ...
  • 文章目录Oracle 创建表Oracle表命名规则使用带有特殊符号的表名使用客户端创建表数据库中的约束约束的作用约束类型主键约束 (Primary ...(Not NULL Constraint)外键约束 (Foreign key Constraint)数据库中表的关系一...
  • Python初学1——语法元素语法框架命名与保留字数据类型 语法框架 缩进 缩进是Python语法一部分,表达代码间层次关系。 缩进必须要有,一般同一...命名规则:大小写字母、数字、下划线和汉字等字符及组合。 注意事
  • 文章目录知识名词解释CAP数据库数据库各部分的命名关系规则键、超键、空值关系代数集合运算自然关系运算运算依赖例题 知识 名词解释 Data Model:一组描述如何用计算机化的信息表示现实世界中的数据的集合,它同时...
  • 8.6.2 使用DML触发器查看表的变更历史 371 8.6.3 DDL触发器 374 8.6.4 分析器日志 377 8.7 最佳实践 379 8.8 总结 380 第9章 表结构与索引 382 9.1 数据库物理结构 383 9.1.1 文件与文件组 383 9.1.2 分区与...
  • 8.6.2 使用DML触发器查看表的变更历史 371 8.6.3 DDL触发器 374 8.6.4 分析器日志 377 8.7 最佳实践 379 8.8 总结 380 第9章 表结构与索引 382 9.1 数据库物理结构 383 9.1.1 文件与文件组 383 9.1.2 分区与...
  • JPA是Java Persistence API的简称,中文名Java持久层API,是JDK 5.0注解或XML描述对象-关系表的映射关系,并将运行期的实体对象持久化到数据库中。 JPA框架中支持大数据集、事务、并发等容器级事务,这使得 ...
  • (一)建表规约 1. 【强制】表达是与否概念字段,必须使用 is_xxx 方式命名,...从 is_xxx 到 Xxx 映射关系。数据库表示是与否值,使用 tinyint 类型,坚持 is_xxx 命名方式是为了明确其取值含义与取值范围
  • 大概翻了一下书店里一些关于Ruby on Rails书籍,和网上一些教材,大多都是讲述rails和MySql的的例子,并且例子中用到的表结构大部份都是使用rails默认主键名称“ID”, 并且大都遵行Rails默认命名规则。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 529
精华内容 211
关键字:

关系表的命名规则