`

数据库主键外键设计原则

阅读更多

主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。

必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境,就很难对这些键进行修改,所以在开发阶段就设计好主键和外键就是非常必要和值得的。

主键:

关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途:

1. 惟一地标识一行。

2. 作为一个可以被外键有效引用的对象。

基于以上这两个用途,下面给出了我在设计物理层面的主键时所遵循的一些原则:

1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据,并抱怨它没有什么用处,那就证明它的主键设计地很好。

2. 主键应该是单列的,以便提高连接和筛选操作的效率。

注:使用复合键的人通常有两个理由为自己开脱,而这两个理由都是错误的。其一是主键应当具有实际意义,然而,让主键具有意义只不过是给人为地破坏数据库提 供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键,我也反对这种做法,理由是:复合主键常常导致不良的外键,即当连 接表成为另一个从表的主表,而依据上面的第二种方法成为这个表主键的一部分,然,这个表又有可能再成为其它从表的主表,其主键又有可能成了其它从表主键的 一部分,如此传递下去,越靠后的从表,其主键将会包含越多的列了。

3. 永远也不要更新主键。实际上,因为主键除了惟一地标识一行之外,再没有其他的用途了,所以也就没有理由去对它更新。如果主键需要更新,则说明主键应对用户无意义的原则被违反了。

注:这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。

4. 主键不应包含动态变化的数据,如时间戳、创建时间列、修改时间列等。

5. 主键应当有计算机自动生成。如果由人来对主键的创建进行干预,就会使它带有除了惟一标识一行以外的意义。一旦越过这个界限,就可能产生认为修改主键的动机,这样,这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。

转载:http://www.cnblogs.com/tianyamoon/archive/2008/04/02/1134394.html

数据库外键的使用

外键的作用我认为主要有两个:一个是让数据库自己通过外键来保证数据的完整性和一致性,一个就是能够增加ER图的可读性。我觉得第二点的重要性甚至比第一点还高。

有些人认为外键的建立会给开发时操作数据库带来很大的麻烦,因为数据库有时候会由于没有通过外键的检测而使得开发人员删除,插入操作失败,他们觉得这样很麻烦,其实这正式外键在强制你保证数据的完整性和一致性,这是好事儿。

应该说如果系统比较小,外键的作用可能不会很明显,如果你的系统后台有几百个表的话,没有外键的数据库设计是我无法想象的,有一个基础数据的表:商 品,其他表都保存商品ID ,查询时需要连表来查询商品的名称,单据1的商品表中有商品ID字段,单据2的商品表中也有商品ID字段,如果不拉出外键的话,当单据1,2都使用商品 ID为3的商品后,删除此商品后,再查看单据1,2的时候就会查不到商品的名称

当表很少的时候,有人认为可以在程序实现的时候来通过写脚本来保证数据的完整性和一致性,也就是在删除商品的操作的时候去检测单据1,2中是否已经使用了商品ID为3的商品,但是当你写完脚本之后系统有增加了一个单据3
他也保存商品ID找个字段,如果不拉出外键,你还是会出现查不到商品名称的情况,你总不能每增加一个使用商品ID的字段的单据时就回去修改你检测商品是否被使用的脚本吧

第二点就是增加ER图的可读性。这也同样是在后台数据库表非常多的时候能够体现出来的,外键能够明确的两个表之间的关系,例如一个单据的主表和单据 的品的子表,如果两个表没有拉出外键表明关系,且两个表的位置在ER图中很远,对于一个对这个系统不是非常了解的人来说,让他去理出两个表之间的关系是很 麻烦的,如果你拉出外键就算两个表离的很远,他也能随着外键找出他们之间的关系来,ER图的可读性对于一个刚刚接触大型系统的新手来说是极为重要的。

当然,外键的个数也不是没有个尺度,因为外键拉的过多会使ER图极为混乱(到处都是线) ,所以应该掌握合适的尺度才行,必要的外键必须要拉出来。如果实在不想因为外键过多而造成ER图的混乱,可以对基础数据的删除用假删除的办法,以避免在没 有外键约束和检查的情况下造成数据的不一致性。

转载:http://blog.csdn.net/dowson2002/archive/2007/08/29/1764148.aspx

uniqueidentifier数据类型

uniqueidentifier数据类型可存储16字节的二进制值,其作用与全局唯一标记符(GUID)一样。GUID是唯一的二进制数:世界上 的任何两台计算机都不会生成重复的GUID值。GUID主要用于在用于多个节点,多台计算机的网络中,分配必须具有唯一性的标识符。 在SQL中 ROWGUIDCOL表示新列是行的全局唯一标识列。对于每个表只能指派一个uniqueidentifier 列作为ROWGUIDCO列。ROWGUIDCOL属性只能指派给uniqueidentifier列
一 什么是uniqueidentifier?
Uniqqueidentifier 是全局唯一的标识

p d [3~)F F C E0二 UniqueIdentifier 数据类型的列如何赋值?
1 使用 NewID()函数 来实现
2 直接将字符串的常量转化成这样的格式 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
举例:6F9619FF-8B86-D011-B42D-00C04FC964FF 为有效的UniqueIdentifier数据
3 直接赋于32位的十六位数据
举例 0xffffffff00000000ffffffff00000000
三 UniqueIdentifier 数据类型 数据实际是怎么在数据库中保存的?
UniqueIdentifier 数据类型存储实际的数据是16个字节的二进制值,
UniQueIdentifier 可以转化成实际的字符串型和二进制数据类型

四 NewID()函数是如何生成唯一的UniqueIdentifier 值的呢?
NewID()函数是从他们的网卡上的标识数字和CPU时钟的唯一的数字生成新的UniqueIdentifier数据 ,这个数据和GUID是一样的每台计算机能生成全球唯一的值
这样在多台计算机和多网络之间生成具有唯一性的标识符

五 使用 Uniqueidentifier数据类型的主要的优点
Uniqueidentifier 数据类型主要的优点是在使用newid函数生成值的时候是可以保证值的全球唯一性
可以唯一的标识单行的记录 对于多库(尤其是多机器,多网段的数据库的复制)来将比IDEntity来的更有效
其次在使用Identity的情况下,我们对自动生成的值是不能修改的,而Uniqueidentifier数据类型是可以随时修改的

六 使用Uniqueidentifier的数据类型的缺点
1 对于生成的Uniqueidentifier 类型的值来讲 ,是无序
在正常显示相关的数据信息的时候,返回的信息是无序的ITPUB个人空间 p e%A _0`2I l(G!v t0]
对于 Identity 为标识的数据显示的时候,默认的情况下是根据添加记录的顺序来显示的。这样,对于uniqueidentifier为主键的信息集 ,还是需要一个默认标识排序的字段。

2 对于Uniqueidentifier 字段来将数据的实际的信息为16个字节,相对来将比Identity来讲 大的多,相对来将 存储空间和查询的效率会降低很多的。

七 在系统数据库的设计中我们如何对Uniqueidentifier,Identity ,和可标识的记录属性(有实际的含义的信息)作为主键 ,这三种方式 进行取舍

以属性为主键的系统设计情况
在系统设计的过程中
单条信息中包含可以表示唯一性的属性(一般不能太多3个以内)而且这样的属性是必填字段。在记录生存周期内一般是不进行改动的,表一般多于50个这样级别的系统
以属性为主键 ,这样的方式还是最佳的

举例: 关于学生的管理信息系统 以学生的学号为主键

以Uniqueidentifier 列为主键的情况
在需要多个数据库之间,多个网段之间需要进行数据库的复制时,我们就需要在每一个唯一的标识来区别每一个单条记录,在没有合适的属性来做主键的情况下可以用Uniqueidentifier列来生成主键

以 Identity为主键的情况
不需要数据库的复制,和系统比较小的情况下(50表以内)可以用 Identity列来生成主键,适合于快速开发。

分享到:
评论

相关推荐

    数据库主键和外键设计的原则.doc

    数据库主键和外键设计的原则

    如何区分SQL数据库中的主键与外键

    在设计数据库时,主键和外键的选择有着重要的原则。首先,主键应该对用户无意义,避免人为干扰;其次,主键最好是单列的,以优化查询和连接操作;主键一旦设定,就不应更新,以免破坏其唯一性;主键也不应包含动态...

    数据库中表的主键设计原则收藏.doc

    "数据库中表的主键设计原则收藏" 在设计数据库表时,主键的设计是非常重要的一步。一个好的主键设计可以提高数据库的性能和可维护性,而一个糟糕的主键设计可能会带来一系列的问题。本文将讨论数据库中表的主键设计...

    深入理解数据库关系:主键与外键的选择与应用

    本文通过详细解释主键和外键的概念、选择原则和实践应用,希望能够帮助读者更好地理解和运用这些数据库设计的基本元素。在设计数据库时,始终牢记数据完整性和业务逻辑,以构建健壮、可维护的数据架构。

    主键和外键.doc

    #### 五、数据库主键选取策略 - **自动增长字段**:最常用的主键选择方式之一,简单易用,适用于大多数场景。 - **手动增长字段**:适用于需要特定顺序或编号的情况,但需要注意避免冲突。 - **GUID/UUID**:全球...

    数据库主键设计原则.txt

    数据库主键设计原则 或许大家都设计过数据库,也为表定义过主键,今天我想阐述的是,应该如何正确的设计一个主键,在以往的一些资料中,都没有提及到主键设计的原则. 我为此总结了一下: 1.是否要采用GUID作为主键 用GUID...

    SQL中的主键和外键.doc

    #### 三、数据库中主键和外键的设计原则 1. **主键设计原则**: - **无意义性**:主键应该对用户没有实际意义,避免用户对主键的依赖。 - **单列性**:主键最好为单列,以提高连接和筛选操作的效率。 - **不可...

    经典数据库设计14个原则

    ### 经典数据库设计14个原则 #### 1. 实体关系的一对一、一对多、多对多关系 - **定义与解释**:在数据库设计中,实体之间的关系通常分为一对一(1:1)、一对多(1:N)或多对多(N:M)。一对一指的是两个实体之间...

    数据库设计原则总结

    本文总结了数据库设计的重要原则,包括原始单据与实体之间的关系、主键与外键的设计、基本表的性质、范式标准、通俗地理解三个范式、要善于识别与正确处理多对多的关系、主键PK的取值方法等七个方面的内容。这些原则...

    数据库设计原则数据库设计原则.docx

    本文将从八个方面详细讲解数据库设计原则,包括原始单据与实体之间的关系、主键与外键、基本表的性质、范式标准、通俗地理解三个范式、要善于识别与正确处理多对多的关系、主键 PK 的取值方法、正确认识数据冗余等。...

    数据库设计原则14法则

    以下是关于“数据库设计原则14法则”的详细解析: 1. 原始单据与实体之间的关系:数据库设计时,需要考虑原始数据源(如业务表格)与实体表之间的映射。通常,一张原始单据对应一个实体,但也有特殊情况,如一对一...

    数据库表设计原则技巧

    ### 数据库表设计原则技巧详解 #### 一、原始单据与实体之间的关系 在数据库设计过程中,理解和处理原始单据与实体之间的关系至关重要。原始单据与实体之间的关系可以是一对一、一对多或者多对多的形式。通常情况...

    数据库建表原则-设计思想-查询优化

    在一个完整的数据库设计中,每个实体至少需要有一个主键或者外键,以便于建立实体之间的联系。 - **主键**:对于位于E-R图中的叶子节点实体来说,可以不定义主键,但必须要有外键来与父实体关联。 - **外键**:外键...

    数据库建表原则 数据库建表原则

    主键与外键的设计,在全局数据库的设计中,占有重要地位。 3. 基本表的性质 基本表与中间表、临时表不同,因为它具有四个特性:原子性、原始性、演绎性和稳定性。理解基本表的性质后,在设计数据库时,就能将基本...

    Oracle数据库开发和设计规范

    本文档总结了 Oracle 数据库开发和设计规范的主要内容,包括命名约定、表名规则、存储过程规则、视图规则、索引规则、序列规则、主键规则和外键规则等。 一、命名约定 Oracle 数据库开发和设计规范中,命名约定是...

    数据库设计原则

    其次,主键和外键是数据库设计的核心元素。主键用于唯一标识一个实体,而外键则用于关联不同的实体。在E-R图中,位于叶子位置的实体如果没有子孙,可以定义主键,但必须有外键来连接其父实体。主键和外键的配合构建...

    oracle数据库设计原则

    以下是一些核心的数据库设计原则和技巧,特别针对Oracle数据库: 1. **第三范式(3NF)**:3NF是数据库设计中常见的规范化程度,旨在减少数据冗余和提高数据一致性。它要求表中的每个非主键字段都完全依赖于主键,...

    Access数据库技术与应用课后习题答案

    1. 论述关系数据库的基本概念(关系、主键、外键) 2. 论述关系数据库的设计原则 3. 论述关系数据库的实现方式(Access 数据库) 第三章 1. 论述数据库的基本概念(表、记录、字段) 2. 论述数据库的设计原则 3. ...

    电子商务网站数据库结构设计

    综上所述,电子商务网站数据库结构设计是一个复杂但至关重要的过程,需要充分理解业务需求,遵循设计原则,合理规划表结构和关系,最终达到支持高并发、大数据量处理的能力,为用户提供流畅的购物体验。

Global site tag (gtag.js) - Google Analytics