表格设计与“人数”

时间:2013-07-31 23:43:09

标签: sql identity uniqueidentifier

我们需要以业务使用的格式存储人员及其“人员编号”。目前,他们使用手动过程为人员编号,例如FP123456。添加的下一个人获得下一个号码,所以FP123457。

根据该号码在系统中进行搜索。

我的想法是使用主键作为数字部分,使用IDENTITY(123456,1),然后使用计算列(不知何故),将当前前缀(FP)附加到主键,给出FPxxxxxx

我想在PersonNumber列上使用默认值(如果可能的话),在插入时,它只是'FP'+ Id。

这是个好主意,还是有可能存在问题?另外,如何在插入时默认列。也许触发器会更好?

4 个答案:

答案 0 :(得分:2)

是的,您可以使用computed column。您可以索引持久计算列。

ALTER TABLE YourTable ADD PersonNumber AS 'FP' + CAST(ID AS VARCHAR(15)) PERSISTED NOT NULL
go

See SQL Fiddle

答案 1 :(得分:2)

我肯定会将此 PersonNumber Primary Key分开。

你会发现那些不同意的人,但根据我的经验,使用natural key作为主键总是是一个糟糕的选择。事情会改变的*。

  • 今天你以一种方式格式化PersonNumber。明天你会得到一个有新想法的新老板,格式会发生变化。然后你的问题不仅是更新一个原始列“PersonNumber”,你还必须更新外键。
  • 明天您可能需要federate,这意味着跨多个数据库或其他系统共享记录。因此,您必须更改主键的使用方式,例如使用UUID值而不是整数值。
  • 在某些时候,您可能需要重建表格,包括导出和导入数据。此时,您需要保留PersonNumber值,但会生成新的主键值。

最重要的是,生成主键的工作可能与生成PersonNumber的工作类似,但它们实际上是两个不同的工作。 Separation of concerns是避免脆弱(易损坏)软件的指导原则。例如,如果PersonNumber生成器以某种方式搞砸了,至少数据库的其余部分(此表中的主键和相关表中的外键)仍将继续运行。

因此使用surrogate key作为主键。然后分别制定管理PersonNumber的策略。

该策略可能涉及用户界面或服务器端应用程序递增数字以生成PersonNumber,如此页面上的SDReyes所建议的那样。

另一个策略是利用数据库服务器为PersonNumber生成序列/序列。如果您有一个严肃的数据库服务器,如MS SQL Server或Postgres,您应该能够创建序列/串行生成器而不必绑定到主键。您可以创建一个调用该序列生成器的触发器,为新记录分配默认值。将构建一个严肃的数据库服务器来处理SDReyes指出的并发问题,以便生成的数字没有重复。但是阅读文档,因为一些序列号生成器可能在序列中有间隙,特别是如果发生事务回滚。如果这是不可接受的,您可能需要找到另一条路线。


*如果您认为这不太可能,请向程序员或系统管理员请求白发。

答案 2 :(得分:1)

我建议你使用不同的自动生成列作为id,类似于int。为什么?因为它非常有效地进行连接,并且允许您在不破坏外部引用的完整性的情况下更改人员编号。

另一个名为“人员编号”的专栏将包含具有唯一性约束的此类编号(例如FP1337)。

答案 3 :(得分:0)

如果您的号码是从外部生成的,那么就使用它。听起来像你已经得到了你的PK。你将来会在某个时候弄错。

如果您建议您从现在开始需要在数据库中生成它们,那么只需使用IDENTITY并且不要使用FP前缀 - 只需在UI处将其关闭。