我们需要以业务使用的格式存储人员及其“人员编号”。目前,他们使用手动过程为人员编号,例如FP123456。添加的下一个人获得下一个号码,所以FP123457。
根据该号码在系统中进行搜索。
我的想法是使用主键作为数字部分,使用IDENTITY(123456,1),然后使用计算列(不知何故),将当前前缀(FP)附加到主键,给出FPxxxxxx
我想在PersonNumber列上使用默认值(如果可能的话),在插入时,它只是'FP'+ Id。
这是个好主意,还是有可能存在问题?另外,如何在插入时默认列。也许触发器会更好?
答案 0 :(得分:2)
是的,您可以使用computed column。您可以索引持久计算列。
ALTER TABLE YourTable ADD PersonNumber AS 'FP' + CAST(ID AS VARCHAR(15)) PERSISTED NOT NULL
go
答案 1 :(得分:2)
我肯定会将此 PersonNumber 与Primary Key分开。
你会发现那些不同意的人,但根据我的经验,使用natural key作为主键总是是一个糟糕的选择。事情会改变的*。
最重要的是,生成主键的工作可能与生成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处将其关闭。