SQL Server - 格式化标识列

发布于 2024-11-28 08:03:49 字数 411 浏览 0 评论 0原文

我希望表中有一个主键列,格式为 FOO-BAR-[身份号码],例如:

FOO-BAR-1  
FOO-BAR-2  
FOO-BAR-3  
FOO-BAR-4  
FOO-BAR-5  

SQL Server 可以这样做吗?或者我必须使用 C# 来管理序列?如果是这样,我如何使用 EntityFramwork 获取下一个 [身份号码] 部分?

谢谢

编辑:

我需要这样做是因为此列代表发送给客户的通知的唯一标识符。

  • FOO 将是一个常量字符串
  • BAR 将根据通知的类型(检测、警告或强制)而有所不同

因此,在 C# 中只使用 int 标识列并将值附加到业务逻辑层中是否更好?

I would like to have a primary key column in a table that is formatted as FOO-BAR-[identity number], for example:

FOO-BAR-1  
FOO-BAR-2  
FOO-BAR-3  
FOO-BAR-4  
FOO-BAR-5  

Can SQL Server do this? Or do I have to use C# to manage the sequence? If that's the case, how can I get the next [identity number] part using EntityFramwork?

Thanks

EDIT:

I needed to do this is because this column represents a unique identifier of a notice send out to customers.

  • FOO will be a constant string
  • BAR will be different depending on the type of the notice (either Detection, Warning or Enforcement)

So is it better to have just an int identity column and append the values in Business Logic Layer in C#?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

羞稚 2024-12-05 08:03:49

如果您希望在报告中使用此“合成”字段,我建议您:

  1. 使用 INT IDENTITY 字段作为表中的 PK
  2. 创建此表的视图。在此视图中,您还可以使用字符串和类型生成所需的字段。
  3. 在您的报告中使用此视图。

但我仍然认为数据库设计存在很大问题。我希望您尝试使用标准化来重新设计。

If you want this 'composited' field in your reports, I propose you to:

  1. Use INT IDENTITY field as PK in table
  2. Create view for this table. In this view you can additionally generate the field that you want using your strings and types.
  3. Use this view in your repoorts.

But I still think, that there is BIG problem with DB design. I hope you'll try to redesign using normalization.

圈圈圆圆圈圈 2024-12-05 08:03:49

您可以将任何内容设置为表中的 PK。但在这种情况下,我会将 IDENTITY 设置为自动递增 int,并根据使用原因在 SQL、BLL 或 UI 中手动将 FOO-BAR- 附加到它。如果 FOOBAR 存在业务原因,那么您还应该将它们设置为数据库行中的值。然后,您可以在数据库中的两三列之间创建一个键,具体取决于您实际使用这些值的原因。

但在我看来,我真的不认为有真正的理由以这种方式连接 ID 并将其存储在数据库中。但话又说回来,我实际上只使用 int 作为我的 ID。

You can set anything as the PK in a table. But in this instance I would set IDENTITY to just an auto-incrementing int and manually be appending FOO-BAR- to it in the SQL, BLL, or UI depending on why it's being used. If there is a business reason for FOO and BAR then you should also set these as values in your DB row. You can then create a key in the DB between the two three columns depending on why your actually using the values.

But IMO I really don't think there is ever a real reason to concatenate an ID in such a fashion and store it as such in the DB. But then again I really only use an int as my ID's.

无需解释 2024-12-05 08:03:49

另一种选择是使用我曾经所在的一个旧团队,称为代码和值表。我们并没有将它用于确切的目的(我们使用它代替自动递增身份以防止某些关键表的环境不匹配),但您可以做的是:

  1. 创建一个表,其中每个类别都有一行。行中的两列(或多列) - 类别名称和下一个数字中的最小值。
  2. 当您在另一个表中插入记录时,您将运行一个存储过程来获取该类别的下一个可用标识号,将代码和值表中的数字增加 1,并将类别和数字连接在一起以进行插入。

但是,如果您的主表是一个包含大量插入的大容量表,那么您可能会得到不按顺序排列的内容。

无论如何,即使数量不是很大,我认为你最好重新检查一下为什么要这样做,看看是否有另一种更好的方法来做到这一点(例如让业务层或 UI 来做这件事) ,正如其他人所建议的那样)。

Another option would be to use what an old team I used to be on called a codes and value table. We didn't use it for precisely this (we used it in lieu of auto-incrementing identities to prevent environment mismatches for some key tables), but what you could do is this:

  1. Create a table that has a row for each of your categories. Two (or more) columns in the row - minimum of category name and next number.
  2. When you insert a record in the other table, you'll run a stored proc to get the next available identity number for that category, increment the number in the codes and values table by 1, and concatenate the category and number together for your insert.

However, if you're main table is a high-volume table with lots of inserts, it's possible you could wind up with stuff out of sequence.

In any event, even if it's not high volume, I think you'd be better off to reexamine why you want to do this, and see if there's another, better way to do it (such as having the business layer or UI do it, as others have suggested).

萌无敌 2024-12-05 08:03:49

通过使用这样的计算列,这是很有可能的:

CREATE TABLE #test (
    id INT IDENTITY UNIQUE CLUSTERED,
    pk AS CONCAT('FOO-BAR-', id) PERSISTED PRIMARY KEY NONCLUSTERED,
    name NVARCHAR(20)
)

INSERT INTO #test (name) VALUES (N'one'), (N'two'), (N'three')

SELECT id, pk, name FROM #test

DROP TABLE #test

请注意,pk 故意设置为 NONCLUSTERED,因为它是 VARCHAR 类型,而 IDENTITY 字段(无论如何都是唯一的)设置为 UNIQUE CLUSTERED。

It is quite possible by using computed column like this:

CREATE TABLE #test (
    id INT IDENTITY UNIQUE CLUSTERED,
    pk AS CONCAT('FOO-BAR-', id) PERSISTED PRIMARY KEY NONCLUSTERED,
    name NVARCHAR(20)
)

INSERT INTO #test (name) VALUES (N'one'), (N'two'), (N'three')

SELECT id, pk, name FROM #test

DROP TABLE #test

Note that pk is set to NONCLUSTERED on purpose because it is of VARCHAR type, while the IDENTITY field, which will be unique anyway, is set to UNIQUE CLUSTERED.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文