根据我的经验,我了解到使用代理INT数据类型列作为主键esp。与使用GUID或char / varchar数据类型列作为主键相比,IDENTITY键列提供更好的性能。 我尝试尽可能使用IDENTITY键作为主键。但最近我遇到了一个模式,其中表格是水平分区的,并通过分区视图进行管理。因此,表格不能具有IDENTITY列,因为这会使分区视图不可更新。解决此问题的一个方法是创建一个带有标识列的虚拟“keygenerator”表,以生成主键的ID。但这意味着每个分区视图都有一个'keygenerator'表。 我的下一个想法是使用float作为主键。原因是我设计的以下关键算法
DECLARE @KEY FLOAT
SET @KEY = CONVERT(FLOAT,GETDATE())/100000.0
SET @KEY = @EMP_ID + @KEY
Heres how it works.
CONVERT(FLOAT,GETDATE())
给出当前日期时间的浮点表示,因为内部所有日期时间都由SQL表示为浮点值。
CONVERT(FLOAT,GETDATE())/100000.0
将浮点表示转换为完整的十进制值,即所有数字都被推到“。”的右侧。
@KEY = @EMP_ID + @KEY
将Employee ID添加为此十进制值的整数。
逻辑是,员工ID保证在会话中是唯一的,因为员工不能同时连接多个应用程序。每次生成密钥时,对于同一名员工,当前日期时间将是唯一的。
所有员工会话中的所有唯一密钥以及跨时间。
因此对于Emp Ids 11和12,我有关键值,如12.40046693321566357,11.40046693542361111
但是,与选择GUID或char / varchar作为主键相比,我担心float数据类型是否为主键提供了好处。同样重要的是因为分区浮点列将成为复合键的一部分。
答案 0 :(得分:1)
我不会考虑这种非正统的密钥生成模式 - 这有一个糟糕的黑客的味道。你为什么不用整数?有许多方法和算法来协调分布式密钥生成。从锁定整个表格并搜索下一个免费ID,通过预先分配每个客户端的id范围,从客户特定信息中获取(类似于您的员工+时间建议)。
答案 1 :(得分:1)
同样重要的是因为分区浮动列将成为复合键的一部分。
什么?为什么?为了使这个基于员工/时间的价值独一无二,您在主键中还需要什么?而在该问题的另一方面,您的密钥的其他组件是否已经是唯一的?如果是这样,为什么不直接使用它们?
你的计划在我的口中留下了不好的味道。我不太清楚为什么,因为,我想的越多,看起来就越坚固。
在考虑了所有这些之后,您的方案看起来确实相对安全。关于没有对索引进行聚类的Edoode's suggestion是一个很好的问题,考虑到这一点,以及上面关于员工ID大小的警告,你可以使用这个方案生成主键,就像任何一个一样。其他方法。
我仍然怀疑它是否是最佳方法,或者是否甚至是必要的。
复合键的其他组件是否可以单独使用(即作为自然键)?
您可以 ,如您所知,在另一个表中保留顺序密钥种子。并且您只需要一个表,而不是每个分区一个表。您只需在此表中有两列:一列用于分区号,另一列用于该分区的当前标识值。
使用GUID或varchar主键并不是不可能的。许多人在许多不同的桌子上这样做。它不会杀死你的表现。它可能比这个方案更直接,或者至少更容易理解。
如果您的组合密钥已包含员工ID,则只需在密钥中添加日期时间列并将其称为一天。如果没有,您可以添加两列。你没有理由将两者混合在一起。
HTH
答案 2 :(得分:0)
由于你没有提到rdbms我会认为SQL服务器。创建主键时,还会创建该键上的聚簇索引。表按此键的顺序排序。当使用Guids作为主键(具有聚簇索引)时,每个插入意味着对表的重新排序。这也适用于您的浮动表示。除了其他问题,如果您希望使用此方案,请不要在此主键上创建聚簇索引。