标签:
有的人有强迫症,他们会为一系列数据的断档而抓狂。
一方面,Id为3这一行确实发生过一些事情,为什么这个查询不返回Id为3的这一行?这条记录数据丢失了吗?那个Column到底是什么?我要为这条数据的丢失负责吗?
大多数人对于断档的第一反应就是想要填补其中的空缺。对此,可能有两种做法:
1、不按照顺序分配编号
你可能想要在插入新行时,通过遍历表,将找到的第一个未分配的主键编号分配给新行,来代替原来自动分配的伪主键机制。随着你不断地插入新行,断档就被填补起来了。
然而,为了找到第一个未被使用的值,你不得不执行一次自联合查询:
SELECT TOP 1 c1.ColumnId + 1 FROM [Columns] AS c1 LEFT OUTER JOIN [Columns] AS c2 ON (c1.ColumnId + 1 = c2.ColumnId) WHERE c2.ColumnId IS NULL ORDER BY c1.ColumnId
如果用SELECT MAX(ColumnId) + 1 这种查询语句,则会出现并发访问的问题,如果有两个程序同时想要找最小的未使用值时,也会出现同样的问题,结果就是一个成功
,另一个失败。况且,这个方法既低效,也容易导致问题。
UPDATE [Columns] SET ColumnId = 3 WHERE ColumnId = 4
2、为现有行重新编号
在某些情况下,你可能急着想要让所有的主键变得连续,而等着新行来填补空缺不够快。你可能会考虑更新现有行的主键值,让其变得连续,从而消除断档。通常这样的做法是找到主键最大的行,然后用最小的未被使用的值来更新它。比如,你可以将4更新为3:
要完成这一步,你需要使用和前面一种方法插入新行类似的方法。先找到一个未被使用的值,随后执行UPDATE语句来重新分配主键值。这两步都会引起并发访问的问题。而且,你需要重复执行很多次这样的操作,才能将较大的断档填满。
你必须同时更新所有引用了你重新分配了主键的行的子记录。如果你在定义外键时,使用了ON UPDATE CASCADE选项,这一步会变得很方便,但如果你没这么做,就必须先禁用约束,手动更新所有的子记录,然后恢复约束。这是一个费时费力且容易出错的操作,并且可能会影响到数据库的服务,正常人都会避免这么做。
即使你完成了清理操作,“整洁”也是个“短命鬼”,如果如果Id是自动生成的,那么对不起,你懂的,Id自增还是按照原来的最大数值增加,比如最大是4,你将4改成了3,但是下一个自动生成的主键依然是5。
3、制造数据差异
重用主键并不是一个好主意,因为断档往往是由于一些合理的删除或者回滚数据引起的。假设一个AccountId为789的用户由于发送带有政治问题的邮件而被封号,产品策略要求删除了这个账号,如果你重用了主键,就会在某一时间点将789分配给另一个用户。而收件人可能在删除后的某一个时间点才打开这些邮件,他们还会投诉789这个Id账号的用户。尽管这个用户本身没有做错任何事情,但是它被分配了一个需要为此负责的编号。
1、定义行号
大多数伪键返回的数字看起来就和行号一样,因为他们就是一次递增的,但这只是由于伪键实现机制所造成的巧合而已。按照这样的方式生成的主键值能比较方便地确保唯一性。
别把主键值和行号混为一谈。主键是用来标识表中记录的,而行号是用来标识查询结果集中记录的。查询结果集的行号和主键值没有一丁点关系,尤其是当你使用了JOIN、GROUP BY或者ORDER BY这些操作符的时候。
有很多使用行号的好理由,比如返回一个查询结果集的子集。通常我们称之为分页,就像在网络搜索时的一页。要选择一个子集,你需要使用到实际的连续增长的行号,但和查询的形式无关。
SQL Server定义了包括ROW_NUMBER()在内的一些窗口函数,返回一个查询结果集中一段连续的行。通常使用行号的作用是将查询结果限制在一个特定的范围内。
2、使用GUID
当然我们还可以生成随机伪键值,只要你不会重复使用任何数字。有些数据库提供全局唯一标识符(GUID)来达到这个目的。
GUID是一个128位的伪随机数(通常用32个),由于GUID的定义及其所要实现的目的,它被设计成具有唯一,因此你可以用其作为伪键。
下面给出用SQL Server使用GUID作为主键的例子:
CREATE TABLE Person( Id UNIQUEIDENTIFIER DEFAULT NEWID(), Name nvarchar(50) )
效果如下:
使用GUID相对于整型自增主键来说有如下两个优势:
下面是使用GUID带来的不便:
SQL:UNIQUEIDENTIFIER <=> .Net GUID
标签:
原文地址:http://www.cnblogs.com/mingxuantongxue/p/4488477.html