精华内容
下载资源
问答
  • 1.数据库设计14规则 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-08-07 11:51:06
    表1 S5700-LI-BAT系列交换机的命名规则 标号 含义 A 表示设备为交换机。 B · 6:下行接口速率为万兆。 · 5:下行接口速率为千兆。 ·...

    S5700-LI-BAT系列交换机的命名如图1所示。

    1 S5700-LI-BAT系列交换机的命名规则

    标号

    含义

    A

    表示设备为交换机。

    B

    · 6:下行接口速率为万兆。

    · 5:下行接口速率为千兆。

    · 3:三层交换机,下行接口速率为百兆。

    · 2:二层交换机,下行接口速率为百兆。

    C

    7:企业网产品系列。

    D

    表示交换机不同系列,如00、10等。

    E

    表示交换机最大可用接口数量。

    F

    表示上行接口的类型,其中:

    · C:表示交换机支持插卡,上行接口为插卡上的接口。

    · X:表示上行接口为交换机上固定的万兆接口。

    · TP:表示上行接口为支持光口和电口的Combo接口。

    · P:表示上行接口为交换机上固定的千兆接口。

    G

    表示交换机类型,其中:

    · LI:表示交换机是简化版本。

    · SI:表示交换机是基本版本。

    · EI:表示交换机是增强版本。

    · HI:表示交换机是高级版本,包含高性能OAM、内置RTC时钟等特性。

    H

    该字段有无表示下行接口的类型:

    · 如果没有该字段表示所有的下行接口均为电口。

    · 如果有该字段,24S表示交换机有24个下行光接口。

    I

    BAT:表示交换机为电池交换机。

    转载至:https://www.sohu.com/a/245123493_717464

    展开全文
  • 软件版本号命名规则

    千次阅读 2018-03-05 19:52:47
    软件版本号命名规则转http://www.newpm.net/pm/77版本号用于区别软件不同的迭代版本,如何命名,应该说是每个公司都有自己的习惯。但是最好还是有一定的规律比较好,这样也能便于其他人了解你的软件更新历程,也不...

    软件版本号命名规则

    版本号用于区别软件不同的迭代版本,如何命名,应该说是每个公司都有自己的习惯。但是最好还是有一定的规律比较好,这样也能便于其他人了解你的软件更新历程,也不至于后期出现版本混乱、难以管理的尴尬。

    先列举一下比较普遍的命名方式:

    1、GUN风格:

    主版本号.子版本号[.修正版本号[.编译版本号]]

    Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]

    示例:1.2.1 、 2.0 、 5.0.0 build-13124

    2、Windows风格:

    主版本号.子版本号[.修正版本号[.编译版本号]]

    Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]]

    示例:1.2.1 、 2.0

    3、.Net Framework风格:

    主版本号.子版本号[.编译版本号[.修正版本号]]

    Major_Version_Number.Minor_Version_Number[.Build_Number[.Revision_Number]]

    版本号由二到四部分组成:主版本号、次版本号、内部版本号、修订号。主版本号和次版本号是必选的,内部版本号和修订号是可选的。但是如果定义了修订号部分,则内部版本号就是必选的。所有定义的部分都必须是大于或者等于0的整数。

    应根据约定使用下面这些部分:

    Major:具有相同名称但不同主版本号的程序集不可互换。它适用于对产品的大量重写,或战略性转变,且无法实现向后兼容性。

    Minor:如果两个程序集的名称和主版本号相同,而次版本号不同,但照顾了向后兼容性。它适用于产品的修正版或完全向后兼容的新版本。

    Build:内部版本号的不同,表示对相同源所做的重新编译。它适合于更改处理器、平台或编译器的情况。

    Revision:名称、主版本号、次版本号都相同,但修订号不同的程序集应该是完全可以互换的。它适用于修复以前发布的程序集中的安全漏洞。

    只有内部版本号或修订号不同的程序集后续版本,才可以被认为是先前版本的修补程序(Hotfix)更新。

    版本号管理策略:

    1、GUN风格:

    (1)产品初版时,版本号可以为0.1或0.1.0,也可以为1.0或1.0.0;

    (2)当产品进行了局部修改或bug修正时,主版本号和子版本号都不变,修正版本号+1;

    (3)当产品在原有的基础上增加了部分功能时,主版本号不变,子版本号+1,修正版本号复位为0;

    (4)当产品进行了重大修改或局部修正累计较多,而导致产品整体发生全局变化的,主版本号+1;

    (5)编译版本号,一般是编译器在编译过程中自动生成的,我们只定义其格式,并不进行人为控制;

    2、Windows风格:

    (1)产品初版时,版本号为1.0或1.0.0;

    (2)当产品进行了局部修改或bug修正时,主版本号和子版本号都不变,修正版本号+1;

    (3)当产品在原有的基础上增加了部分功能时,主版本号不变,子版本号+1,修正版本号复位为0;

    (4)当产品进行了重大修改或局部修正累计较多,而导致产品整体发生全局变化的,主版本号+1;

    (5)编译版本号,一般是编译器在编译过程中自动生成的,我们只定义其格式,并不进行人为控制;

    一些付费软件在升级的时候也需要购买,那么这个所谓的升级,一般是指主版本号的变更。

    另外,还可以在版本号后面加上Alpha、Beta、Gamma、Current、RC(Release Candidate)、Release、Stable等后缀,在这些后缀后面还可以加上1位数字的版本号。

    Android版本号:

    1、主版本号变化

    Android2.x:仅支持手机等小平移动设备;

    Android3.x:只支持平板和电视等大屏设备;

    Android4.x:合并了2.x和3.x,支持多种设备;

    2、次版本号变化

    功能增加;

    3、维护版本号变化

    修复漏洞、bug;

    4、构建版本号变化

    变化周期频繁且不固定,针对开发人员内部使用;

    内部测试版本号使用建议:

    主版本号.次(子)版本号.修正版本号.日期版本号_阶段版本号_(修改次数)_开发者缩写

    例如:1.0.1.150325_beta_b3_ZainF

    附录:

    α(alpha)内部测试版

    α版表示该产品只是一个初步完成的产品,通常只用于在开发者内部交流,也有很少一部分发布给专业的测试人员,一般情况下,该版本会存在较多bug,不适合普通用户使用。

    β(Beta)外部测试版

    该版本相对于α版已经有了很大改进,消除了严重的错误,但可能依然存在一些缺陷,需要经过大规模的发布测试进一步发现、消除错误。这一版本通常由软件公司免费发布,通过一些专业的爱好者测试,将结果反馈给开发人员,开发者们再进行有针对性的修改,该版本一般不适合普通用户大规模安装使用。

    γ(Gamma)

    表示该版本已经相当成熟,与即将发行的正式版相差无几。

    trial(试用版)

    改类产品通常都有时间限制,或者在功能上相对于正式版做了一些限制。在试用版中,用户可以通过注册或购买来获得正式的产品。

    unregistered(未注册版)

    与试用版类似,只是未注册版通常没有使用时间限制,但在功能上同样做了一定的限制。也可能无休止的弹出注册提示。

    demo(演示版)

    在非正式版本的产品中,此版本的知名度最大。demo版仅仅集成了正式版中的几个功能,也不能通过升级或注册成为正式版。

    不同类型的正式版软件通常也有区别:

    release(最终释放版)

    意味着在出了一系列测试版之后,终归会有一个正式版,该版本有时也会被称作:标准版。一般情况下,release不会以单词的形式出现在软件封面上,而是以符号(r)替代。例如:Windows NT(r)4.0、ms-dos(r)6.22等。

    registered(注册版)

    相对于unregistered(非注册版)。

    standard(标准版)

    无论什么产品,标准版一定存在,而且最常见。标准版中通常包含了该软件的基本组件以及一些常用功能,可以满足用户的一般需求,其价格相对高级版本也更加平易近人。

    deluxe(豪华版)

    通常相对于标准版而言,主要区别是多了几项功能,价格也相对较高。

    reference

    该版本型号常见于百科全书中,比较有名的是微软的Encarta系列。reference是最高级别,其中包含主题、图像、影片剪辑等。相对于standard和deluxe版均有大幅增加,容量由一张光盘猛增至三张光盘,并且加入了很强的交互功能。同时价格不菲,适合发烧友用户收藏。

    professional(专业版)

    专业版是针对某些特定的开发工具软件而言的。专业版中有许多内容是标准版所没有的,这些内容对于一个专业的软件开发人员来说是极为重要的。

    enterprise(企业版)

    企业版是开发类软件中的极品。可以通过它毫无障碍的开发任何级别的应用软件。而这一版本的价格也是一般普通用户所无法承受的。

    除了以上这些,还有一些专有版本名称:

    update(升级版)

    升级版的软件不能独立使用,该版本的软件会在安装过程中搜索原有的正式版,如果不存在,则会拒绝下一步。

    oem

    oem版通常是捆绑在硬件中而不能单独销售的版本。将自己的产品交给别的公司卖,保留自己的著作权,双方互惠互利。

    单机/网络版

    网络版在结构、功能上远比单机版要复杂,且建个也要更加昂贵。

    普及版

    有时也成为共享版。价格便宜,甚至免费、功能单一、针对性强(可能用户占领市场或者打击盗版)。

    更多版本名称:

    英文名称中文释义
    Enhance增强版或者加强版,属于正式版
    Free自由
    Full version完全版,属于正式版
    Shareware共享版
    Release发行版,有时间限制
    Upgrade升级版
    Retail零售版
    Cardware属共享软件的一种,只要给作者回复一封电邮或明信片即可。(有的作者并由此提供注册码等),目前这种形式已不多见。
    Plus属增强版,不过这种大部分是在程序界面及多媒体功能上增强。
    Preview预览版
    Corporation & Enterprise企业版
    Standard标准版
    Mini迷你版也叫精简版只有最基本的功能
    Premium贵价版
    Professional专业版
    Express特别版
    Deluxe豪华版
    Regged已注册版
    CN简体中文版
    CHT繁体中文版
    EN英文版
    Multilanguage多语言版
    展开全文
  • 电脑主机命名规则|活动目录计算机命名规则。大家好,我们公司大概有2000个客户端。AD环境。现在关于主机命名规则分成了2种意见:一种主张采用资产编号作为主机名。一种主张结合用户账号作为主机名(地点-用户账号-...
      
    

    电脑主机命名规则|活动目录计算机命名规则。大家好,我们公司大概有2000个客户端。AD环境。现在关于主机命名规则分成了2种意见:一种主张采用资产编号作为主机名。一种主张结合用户账号作为主机名(地点-用户账号-序列号)。现在2种方式各有优缺点,但是不好决定用什么方式。所以想请教一下各位的经验,大家在各个公司AD环境下,通常采用什么命名规则来命名主机。同时,你认为采用这种命名规则有什么好处呢?算是做一个小小的调查吧,为我们更多的网管们提供一个参考,谢谢大家。

    回答:我是这样考虑的:
    1、资产编号
    优点:资产编号是唯一的,不变的。如果资产所有人发生变动不会造成主机名称的变化。这样可以减少用户和终端支持的工作。
    每台主机都是资产编号显示在系统里面,对于资产的管理是不是会有一定好处呢?
    缺点:资产编号不直观,对管理员来说看到资产编号不知道这个机器是谁在用的。对于用户来说,网络访问用资产编号很不方便。同时,如果一个人或服务器的资产换了,那别人访问他是不是也要换名字呢。
    2、结合域帐号
    优点:通过机器名就能比较容易知道主机是谁的?服务器是做什么用的?
    网络访问方便,这个名称比编号好使用,而且即使资产换了,但主机名是不变的
    缺点:主机名称是可变的。如果资产所有人发生变化同时需要变换主机名,增加用户和终端支持的工作。
    同时由于资产管理系统没有主机名的记录,对于计算机信息的记录和收集都有问题。

    我知道还有公司采用位置作为主机名,比如地点楼层座位号。可能主要的问题还在于计算机信息包括资产的记录收集统计分析。。。但是通过计算机名称能解决这个问题吗?
    ---niesri

    本人的理解
    1、资产编号
    优点:同解
    缺点:你有2000个客户端,对管理员来说,不必要也不可能知道是谁在用机器,老板除外,当然,老板对IT服务是应该有绿色通道的,呵呵.
    您提到"服务器的资产换了",我就纳闷了,机器的资产编号怎么可以换呢,从你买进机器到捐给希望工程,这个资产编号是不应该有更换的,我想财务部应该是第一个反对更改资产标签的吧.
    您提到"对于用户来说,网络访问用资产编号很不方便",我想您不可能指的是客户端访问客户端吧,应该是客户端访问服务器.那服务器的主机名则可以不用资产编号.我的做法是"公司简写+国家代码+服务器类型+数字",如MS CN DC 001代表微软公司在中国地区的第一台DC.

    至于结合域帐号,你有2000个客户端,除非公司福利特好,否则我想人员的流进流出应该很频繁,咨询一下HR部门先.
    ---windcar

    我们公司是这样子使用的,比如说公司名称简称叫作YZ,部门是HR,那么命名方式就是YZ-HR001,YZ-HR002,除非这个电脑转出此部门,否则不改名字的,另外具体到哪个人用,可以在计算机说明当中注明,这样子基本上不用更改HOSTNAME的。。
    ---night1879

    缺点:资产编号不直观,对管理员来说看到资产编号不知道这个机器是谁在用的。对于用户来说,网络访问用资产编号很不方便。同时,如果一个人或服务器的资产换了,那别人访问他是不是也要换名字呢。
    我觉得如果你用第一个方法可能好点儿吧,首先2000个客户端,你可能让大家互相之间访问共享的吧。只可能访问文件服务器,而文件服务器是可以做别名共享的。
     ---zwphoenix

    资产编号也不能方便解决你的需要 我得感觉 如果client数量多的话 你岂不是要写个代码查询了。建议是采用 国家-区域-部门-编号 这样更直观
    ---soki

    微软的建议是使用尽可能不会发生变化的名称,比如地名、国家名、历史名、星球名等等。由于部门、人员、电话等都是很容易发生变化的id,故而不建议采用。
    可以考虑采用 公司名+地名+流水号就可以了。这样无论谁使用这台计算机,或者是这台计算机搬到哪个部门去了,都不用变更名称。
    当然如果搬到外地去了,这样的几率比较小。
    ---gnaw0725

    展开全文
  • 软件发布版本命名规则 1 版本类型 1.1 正式版本 Enhance:增强版或者加强版,属于正式版; Full:完全版,属于正式版; Release:发行版,有时间限制; Upgrade:升级版; Retail:零售版; Plus:增强版,...
  • 数据库及实体命名规则

    千次阅读 2015-07-14 11:11:10
    数据库表名、字段名命名规则: 1、使用拼音方式命名 2、如果存在多个层次或多个短语,则使用“_”来分隔不同的层次或短语 3、如果短语中对应的中文超过2个汉字,则采用首字母 4、如果短语中对应的中文为2个汉字...
  • restful 接口命名规则

    万次阅读 2016-10-27 16:06:36
    而这里你只需要一个endpoint:/tickets,再没有其他什么命名规则和url规则了,cool!   这个endpoint的单数复数 一个可以遵从的规则是:虽然看起来使用复数来描述某一个资源实例看起来别扭,但是...
  • Cisco交换机命名规则

    千次阅读 2011-01-05 16:00:00
    Cisco交换机命名规则 目前工作中经常接触到的交换机有:2960,3560,3750,4500,6500这些系列,它们在型号命令上有自己相应的规则,总结如下:  例如:WS-C3750G-48TS-S  C3750表明这款产品...
  • [转载]软件版本命名规则 (2011-08-29 08:35:49)转载▼标签: 转载 原文地址:软件版本命名规则作者:晨风=====常见的版本控制有三种命名格式,分别如下 =====一、GNU 风格的版本号命名格式 :主版本...
  • 软件版本号的命名格式和规则

    千次阅读 2014-01-19 03:09:58
    版本控制比较普遍的 3 种命名格式 : 一、GNU 风格的版本号命名格式 : 主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]] Major_Version_Number.Minor_Version_Number[.Revision_Number[.Build_Number]] 示例 : ...
  • 但是相比于普通电脑,人们对服务器了解的可以说是甚少,面对高大服务器(5U塔式)或者样式“怪异”(机架式)的服务器,人们往往有种茫然无措的感觉,其实目前中小企业和个人接触比较密切的服务器基本上只有塔式和...
  • Intel CPU命名规则的简略解析

    千次阅读 2019-09-27 21:42:01
    Intel的CPU命名规则一直不是特别清楚,而网上的很多解读是不准确,甚至是错误的,应该以官方文档为准。所以我在查阅官方资料的基础上,以一种简明扼要的方式记录下来。值得说明的是,这个解析只是简略的,一般人只要...
  • cisco设备模块命名规则

    千次阅读 2018-11-28 16:56:27
    路由的命名规则都是以CISCO开头比如:cisco1721,cisco2621,cisco3662,cisco3745。这些都是路由器。   比如: cisco2621  其中cisco:是品牌,后面的前两位数字是系列号,这款产品属于2600系列,后两位是具体...
  • 数据表结构的张秋范式命名规则

    千次阅读 2009-09-03 18:42:00
    基本原则:所有业务逻辑相关的字段(栏位),具有唯一的名字。2.系统模块编码为2个或3个英文字母。所有命名一律大写。3.数据表命名由模块编码加2位英文字母,即由4个或5个大写英文字母组成。4.数据表字段命名由表名...
  • 软件项目版本号的命名规则及格式

    千次阅读 2016-08-01 09:48:38
    原文链接:软件项目版本号的命名规则及格式 版本控制比较普遍的 3 种命名格式 :一、GNU 风格的版本号命名格式 :主版本号 . 子版本号 [. 修正版本号 [. 编译版本号 ]] Major_Version_Number.Minor_Version_Number[....
  • 三极管命名规则[zz]

    千次阅读 2013-11-10 18:15:19
    这是三极管最基本的和最重要的特性。我们将ΔIc/ΔIb的比值称为晶体三极管的电流放大倍数,用符号"β"表示。电流放大倍数对于某一只三极管来说是一个定值,但随着三极管工作时基极电流的变化也会有一定的改变。 ...
  • 在进行原理图设计过程中,对于元件标号(英文为:Designator,即元件符号的标号,默认简称为:元件标号)的命名规则,一直都没有特定的标准,一般采用的是约定俗成的命名规则企业与公司内部的命名标准。在企业和...
  • 但是相比于普通电脑,人们对服务器了解的可以说是甚少,面对高大服务器(5U塔式)或者样式“怪异”(机架式)的服务器,人们往往有种茫然无措的感觉,其实目前中小企业和个人接触比较密切的服务器基本上只有塔式和...
  • H3C全系列网络产品命名规则介绍

    千次阅读 2015-10-11 14:22:05
     ER系列路由命名规则: 第一位数字:3系列是百兆接口,5系列是千兆接口。 第二位数字:1代表单WAN口,2代表双WAN口。 ER3000系列为全百兆接口。 ER5000系列上行百兆,下行千兆接口。 ER6300/ER8300为全千兆...
  • 服务器命名规则 服务器对于企业IT建设的重要性不言而喻,并且随着科技的进步,服务器已经开始逐步走进企业,甚至被更多个人家庭用户所熟知。但是相比于普通电脑,人们对服务器了解的可以说是甚少,面对高大...
  • 思科IOS软件命名规则简单介绍

    千次阅读 2011-03-21 10:54:00
    思科IOS软件命名规则简单介绍: AAAAA-BBBB-CC-DDDD.EE 1. AAAAA 这组字符是说明文件所适用的硬件平台, 2. BBBB 这组字符是说明这个IOS中所包含的特性, 3. CC 这组字符是IOS文件格式, 4. DDDD 这组...
  • 数据仓库学习(三)——命名规则

    千次阅读 2018-07-10 23:15:20
    笔者是一个痴迷于挖掘数据中的价值的学习人,希望在平日的工作学习中,挖掘数据的价值,找寻数据的秘密,笔者认为,数据的价值不仅仅只体现在企业中,个人也可以体会到数据的魅力,用技术力量探索行为密码,让大数据...
  • 服务器命名规则--IBM、惠普、戴尔

    千次阅读 2013-07-11 11:54:07
    但是相比于普通电脑,人们对服务器了解的可以说是甚少,面对高大服务器(5U塔式)或者样式“怪异”(机架式)的服务器,人们往往有种茫然无措的感觉,其实目前中小企业和个人接触比较密切的服务器基本上只有塔式和...
  • 软件项目版本号的命名规则及格式介绍 June 13, 2007 at 14:10 · Filed under 机械境 版本控制比较普遍的 3 种命名格式 : 一、GNU 风格的版本号命名格式 : 主版本号 . 子版本号 [. 修正版本号 ...
  • 软件编程命名方法+数据库命名

    千次阅读 2014-03-15 10:07:16
    几种常见的程序设计中命名规则   正确并形象地给函数、变量命名,不仅可以增加程序的可读性,也是程序员编程风格的一种反映。较好的命名习惯,可以有效的提高程序的可维护性。以下介绍几种常用的变量命名规则。  ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 50,606
精华内容 20,242
关键字:

企业命名的基本规则