Question

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

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

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

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

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

Answer 1

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

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

See SQL Fiddle

Answer 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指出的并发问题，以便生成的数字没有重复。但是阅读文档，因为一些序列号生成器可能在序列中有间隙，特别是如果发生事务回滚。如果这是不可接受的，您可能需要找到另一条路线。

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

Answer 3

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

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

Answer 4

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

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

表格设计与“人数”

4 个答案: