逻辑数据库设计 - 需要ID(谈主键Id)

每个了解数据库设计的人都知道，主键对于一张表来说是一个很重要，甚至必需的部分。这确实是事实，主键是好的数据库设计的一部分。主键是数据库确保数据行在整张表唯一性的保障。它是定位到一条记录并且确保不会重复存储的逻辑机制。主键也同时可以被外键引用来建立表与表之间的关系。

难点是选择那一列作为主键。大多数表中的每个属性值都有可能被很多行使用。例如姓名，电子邮件地址等等都不能保证不会重复。

在这样的表中，需要引入一个对于表的域模型无意义的新列来存储一个伪值。这一列被用作这张表的主键，从而通过它来确定表中的一条记录，即便其他的列允许出现适当的重复项。这种类型的主键列我们通常称其为伪主键或者代理键。

大多数数据库提供一种和当前处理事务无关的底层方案，来确保每次都能生成全局唯一的一个整数作为伪主键，即使客户端此时正发起并发操作。

主键存在的作用：

1、确保一张表中的数据不会出现重复行。

2、在查询中引用单独的一行记录。

3、支持外键。

很多的书、文章以及程序框架都会告诉你，每个数据库的表都需要一个主键，且具有如下三个特性：

(1)、主键的列名都叫做Id；

(2)、数据类型是32位或者64位的整数

(3)、主键的值是自动生成来确保唯一的。

在每张表中都存在一个叫做Id的列是如此地平常，甚至Id已经成为了主键的同义词。很多程序员在一开始学习SQL时就被灌输了错误的概念。认为每张表都要增加一列Id，这显然太过于随意。

1、冗余键值

2、允许重复项

一个组合键包含了多个不同的列，组合键的典型场景就是想上节中乱穿马路中的Contact表。主键需要确保一个给定的Product_Id和Account_Id的组合在整张表中只能出现一次，虽然同一个值可能在很多不同的配对出现。

然而，当你使用了Id这一列作为主键，约束就不是Account_Id和Product_Id的组合必须唯一了。当你用这张交叉表去查询Account_Id和Product_Id的关系时，重复项会意料之外的结果。要确保没有重复项，你可以在Id之外，额外声明另外两列需要一个UNIQUE约束。但是当你在Account_Id和Product_Id这两列上应用了唯一性约束，Id这一列就会变成了多余的列。它已经背离了主键的初衷了。

3、关键字意义不明确

Id这个词是如此地普通，完全无法表达更深沉的意思，特别是在你做两张表连接查询，而他们都有一个叫做Id的主键时。

　　select *　　from Accout as a　　join Bug b on (b.toId = a.Id) 

这种查询必须在查询时指定列别名，否则其中的一个Id列会覆盖掉另一列的Id的值。

同时有两张表有相同的Id列的情况下也不能够使用using关键字。

比如：SQL支持一种简洁的表达式来表示两张表联结(using)。如果两张表有同样的列名，就可以用如下的表达式来重写上面的需求。

select * from Account join Bug using(Bug_id);　　--一个主键，一个外键。

然而，如果所有的表都要求定义一个叫做id的伪主键，那么将不能使用这种简写方式。 

4、使用组合键

一些开发人员觉得组合键太难使用，如果要比较两个键值，必须比较其包含的所有列的值；一个引用组合键的外键，其本身也必须是一个组合外键。此外，使用组合键需要打更多的字。其实这是不对的。组合键的适当的时候是应该被使用的。

 　　1、我觉得这张表不需要主键。

这么说的人一定是误解了“主键”和“伪主键”的含义，每张表都必须要有一个主键，这个是毫无疑问的。实际上可能这个人需要的是一个组合键，或者一个更自然的列名来做主键。

2、我怎么能在多对多的表中存储重复的项？

在一个对多对关系的交叉表中需要声明一个主键约束。或者至少需要有一个针对那些被引用作为外键的唯一约束。

 　　使用伪主键，或者通过自动增长的整型的机制本身没有什么错误，但不是每张表都需要一个伪主键，更没有必要将每个伪主键都定义成Id。

 　　对于太长而不方便实现的自然键来说，伪主键是一个很好的代替品。比如在一个记录文件系统的所有文件属性的表中，文件路径是一个很好的自然键，但对一个字符串列做索引的开销会很大。

 　　主键是约束而非数据类型。你可以定义任意列或任意多个的列作为主键。只要其数据类型支持索引。另外在此必须要补充的是，在SqlServer中，主键和聚集索引并没必然的关系。SqlServer只是默认将聚集索引建在主键上，实际上你完全可以将聚集索引手动定义到非主键列。

 　　1、为主键选择更有意义的名称

比如为Product这张表的主键应该叫做Product_Id。

2、外键应该尽可能地和所引用的列使用相同的名称，这通常意味着：一个主键的名称应该在整个数据库的设计中唯一；任意两张表都不应该使用相同的名称来定义主键，除非其中之一引用了另外一个作为外键。然而凡是都有例外，又是外键的名称需要和其所引用的主键区分开，从而使的它们之间的引用关系表现得更加清晰。

 　 比如在一张外键表中将外键声明为create_by(由谁创建)。　　

如果你的表中包含一列能够确保唯一、非空以及能够用来定位一条记录，就别仅仅因为传统而觉得有必要再加上一个伪主键。

实践证明，一张表中的每一列都在最初的设计之后遭遇改变是很正常的事情。数据库的设计趋向于在整个项目的声明周期中不断地调整和优化，并且决策者也可能一点也不在乎自然键的“神圣不可侵犯”。有时候一个列最开始是像是个很好的自然主键，但随后有允许合法的重复项。此时伪主键便成了唯一的选择。

在合适的时候也可以使用联合主键，比如一条记录可以通过多个列的组合完全定位。就像上面提到的Contact表，那就通过那些列创建一个联合主键吧。

总结：我个人的见解就是能用代理键就尽量用代理键。除非代理键真的非常多余，就好似上面的组合键代替复合键的例子一样。

逻辑数据库设计 - 需要ID(谈主键Id)

标签：

小编还为您整理了以下内容，可能对您也有帮助：

如何设计数据库的主键

有些朋友可能不提倡数据库表必须要主键，但在我的思考中，觉得每个表都应该具有主键，不管是单主键还是双主键，主键的存在就代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，本记录的修改与删除，当我们没有主键时 有些朋友可能不提倡数据库表必须要主键，但在我的思考中，觉得每个表都应该具有主键，不管是单主键还是双主键，主键的存在就代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，本记录的修改与删除，当我们没有主键时，这些操作会变的非常麻烦。

我强调主键不应该具有实际的意义，这可能对于一些朋友来说不太认同，比如订单表吧，会有“订单编号”字段，而这个字段呢在业务实际中本身就是应该具有唯一性，具有唯一标识记录的功能，但我是不推荐采用订单编号字段作为主键的，因为具有实际意义的字段，具有“意义更改”的可能性，比如订单编号在刚开始的时候我们一切顺利，后来客户说“订单可以作废，并重新生成订单，而且订单号要保持原订单号一致”，这样原来的主键就面临危险了。因此，具有唯一性的实际字段也代表可以作为主键。因此，我推荐是新设一个字段专门用为主键，此主键本身在业务逻辑上不体现，不具有实际意义。而这种主键在一定程序增加了复杂度，所以要视实际系统的规模大小而定，对于小项目，以后扩展不会很大的话，也查允许用实际唯一的字段作主键的。

我们现在在思考一下，应该采用什么来作表的主键比较合理，申明一下，主键的设计没有一个定论，各人有各人的方法，哪怕同一个，在不同的项目中，也会采用不同的主键设计原则。 编号作主键

此方法就是采用实际业务中的唯一字段的“编号”作为主键设计，这在小型的项目中是推荐这样做的，因为这可以使项目比较简单化，但在使用中却可能带来一些麻烦，比如要进行“编号修改”时，可能要涉及到很多相关联的其他表，就象黎叔说的“后果很严重”;还有就是上面提到的“业务要求允许编号重复时”，我们再那么先知，都无法知道业务将会修改成什么?

自动编号主键

这种方法也是很多朋友在使用的，就是新建一个ID字段，自动增长，非常方便也满足主键的原则，优点是：数据库自动编号，速度快，而且是增量增长，聚集型主键按顺序存放，对于检索非常有利;数字型的，占用空间小，易排序，在程序中传递也方便;如果通过非系统增加记录(比如手动录入，或是用其他工具直接在表里插入新记录，或老系统数据导入)时，非常方便，不用担心主键重复问题。

缺点：其实缺点也就是来自其优点，就是因为自动增长，在手动要插入指定ID的记录时会显得麻烦，尤其是当系统与其他系统集成时，需要数据导入时，很难保证原系统的ID不发生主键冲突(前提是老系统也是数字型的);如果其他系统主键不是数字型那就麻烦更大了，会导致修改主键数据类型了，这也会导致其他相关表的修改，后果同样很严重;就算其他系统也是数字型的，在导入时，为了区分新老数据，可能想在老数据主键前统一加一个“o”(old)来表示这是老数据，那么自动增长的数字型又面临一个挑战。

Max加一

由于自动编号存在那些问题，所以有些朋友就采用自己生成，同样是数字型的，只是把自动增长去掉了，采用在Insert时，读取Max值后加一，这种方法可以避免自动编号的问题，但也存在一个效率问题，如果记录非常大的话，那么Max()也会影响效率的;更严重的是并发性问题，如果同时有两人读到相同的Max后，加一后插入的ID值会重复，这已经是有经验教训的了。

自制加一

考虑Max加一的效率后，有人采用自制加一，也就是建一个特别的表，字段为：表名，当前序列值。这样在往表中插入值时，先从此表中找到相应表的最大值后加一，进行插入，有人可能发现，也可能会存在并发处理，这个并发处理，我们可以采用lock线程的方式来避免，在生成此值的时，先Lock，取到值以后，再unLock出来，这样不会有两人同时生成了。这比Max加一的速度要快多了。但同样存在一个问题：在与其他系统集成时，脱离了系统中的生成方法后，很麻烦保证自制表中的最大值与导入后的保持一致，而且数字型都存在上面讲到的“o”老数据的导入问题。因此在“自制加一”中可以把主键设为字符型的。字符型的自制加一我倒是蛮推荐的，应该字符型主键可以应付很多我们意想不到的情况。

GUID主键

目前一个比较好的主键是采用GUID，当然我是推荐主键还是字符型的，但值由GUID生成，GUID是可以自动生成，也可以程序生成，而且键值不可能重复，可以解决系统集成问题，几个系统的GUID值导到一起时，也不会发生重复，就算有“o”老数据也可以区分，而且效率很高，在.NET里可以直接使用System.Guid.NewGuid()进行生成，在SQL里也可以使用 NewID()生成。 优点 同 IDENTITY 列相比，uniqueidentifier 列可以通过 NewID() 函数提前得知新增加的行 ID，为应用程序的后续处理提供了很大方便。

便于数据库移植，其它数据库中并不一定具有 IDENTITY 列，而 Guid 列可以作为字符型列转换到其它数据库中，同时将应用程序中产生的 GUID 值存入数据库，它不会对原有数据带来影响。

便于数据库初始化，如果应用程序要加载一些初始数据， IDENTITY 列的处理方式就比较麻烦，而 uniqueidentifier 列则无需任何处理，直接用 T-SQL 加载即可。

便于对某些对象或常量进行永久标识，如类的 ClassID，对象的实例标识，UDDI 中的联系人、服务接口、tModel标识定义等。 缺点 GUID 值较长，不容易记忆和输入，而且这个值是随机、无顺序的。

GUID 的值有 16 个字节，与其它那些诸如 4 字节的整数相比要相对大一些。这意味着如果在数据库中使用 uniqueidentifier 键，可能会带来两方面的消极影响：存储空间增大;索引时间较慢。 我也不是推荐GUID最好，其实在不同的情况，我们都可以采用上面的某一种方式，思考了一些利与弊，也方便大家在进行设计时参考。

数据库如何设置主键(ID)自动增长啊(SQL语句)

在创建表的时候可以设置，方法如下，用一下sql语句。

create table tableName(

id int identity(1,1) primary key，data varchar(50))

解释：其中identity(1,1)代表自增，第一个1代表从1开始计数，第二个1代表每次增长1。

SQL 全名是结构化查询语言[1]（Structured Query Language），是用于数据库中的标准数据查询语言，IBM 公司最早使用在其开发的数据库系统中。1986年10月，美国国家标准学会(ANSI) 对 SQL 进行规范后，以此作为关系式数据库管理系统的标准语言 (ANSI X3. 135-1986)，1987年得到国际标准组织的支持下成为国际标准。不过各种通行的数据库系统在其实践过程中都对 SQL 规范作了某些编改和扩充。所以，实际上不同数据库系统之间的SQL不能完全相互通用。

百科-SQL语言

数据库中id指的是什么?

ID在不同的地方有不同的意思，这里我们简单讲一下在数据库里的ID。

数据库里头，我们建表的时候通常唯一标识叫ID。

Thread对象也有ID，可以通过getId来获取，这个ID是自增长的。

数据库中id指的是什么?

ID在不同的地方有不同的意思，这里我们简单讲一下在数据库里的ID。

数据库里头，我们建表的时候通常唯一标识叫ID。

Thread对象也有ID，可以通过getId来获取，这个ID是自增长的。

为什么用access设计数据库时候要定义个ID(自动编号)?

ID一般是作为主键的,是一条数据的唯一编号
删除或更新数据的时候是以ID作为依据的
就像你学号在你的学校中是唯一的一样

建议:看一下关系型数据库的定义

可以不定义,但是不能保证你的数据中不出现重复的数据
而且在对数据库进行操作的时候会比较困难

虽然你没有定义ID字段,但是你同样要定义一个其他的字段来顶替ID字段的作用,否则你根本无法对数据库进行更新删除操作

为什么用access设计数据库时候要定义个ID(自动编号)?

ID一般是作为主键的,是一条数据的唯一编号
删除或更新数据的时候是以ID作为依据的
就像你学号在你的学校中是唯一的一样

建议:看一下关系型数据库的定义

可以不定义,但是不能保证你的数据中不出现重复的数据
而且在对数据库进行操作的时候会比较困难

虽然你没有定义ID字段,但是你同样要定义一个其他的字段来顶替ID字段的作用,否则你根本无法对数据库进行更新删除操作

数据库设计过程中表的表的主键id的长度可以为0吗

题主是否想询问“数据库设计过程中表的主键id的长度可以为0吗”？可以。在数据库设计的知识中的，数据库设计过程中表的主键id的长度会进行自动排序，0会从1开始递增，长度是可以位0的。数据库设计是指根据用户的需求，设计数据库的结构和建立数据库的过程。

数据库中什么是主键，什么是外键

主键（Primary key）： 也称为主码或主关键字，用于惟一地确定一个元组的属性或属性组(复合主码)。每个关系都有一个并且只有一个主码。

外键（Foreign Key）：也称为外码或外部关键字。如果一个属性集不是所在关系的关键字，但是是其他关系的关键字，则该属性集称为外部关键字。

在关系数据库中可以通过外键使两个关系关联，这种联系通常是一对多（1：n）的，其中主（父）关系（1方）称为被参照关系，从（子）关系（n方）称为参照关系。

扩展资料：

数据库主键作用:

1、保证实体的完整性

2、加快数据库的操作速度

3、在表中添加新记录时，DBMS会自动检查新记录的主键值，不允许该值与其他记录的主键值重复。

4、DBMS自动按主键值的顺序显示表中的记录。如果没有定义主键，则按输入记录的顺序显示表中的记录。

在有些数据库中，虽然主键不是必需的，但最好为每个表都设置一个主键，不管是单主键还是复合主键。它存在代表着表结构的完整性，表的记录必须得有唯一区分的字段，主键主要是用于其他表的外键关联，以及本记录的修改与删除。

参考资料来源：百度百科-数据库主键