1

我的数据库中有几个表只包含“元数据”。例如，我们有不同的 grouptypes、contentItemTypes、languages 等。

问题是，如果您使用自动编号，那么您可能会产生间隙。id 在我们的代码中使用，所以数字非常重要。

现在我想知道是否最好不要在这些表中使用自动编号？

现在我们首先在数据库中创建了行，然后才能编写代码。在我看来，情况不应该如此。

你们有什么感想？

4

5 回答 5

2

我会按照您的建议使用标识列作为主键（代理键），然后将您的候选键（系统中的标识符）分配为标准列，但对其应用唯一约束。这样您可以确保不插入重复记录。

说得通？

于 2009-09-04T07:55:45.363 回答
1

如果这些是仅用于将代码扩展为描述或包含其他属性的 FK 表，那么我不会使用 IDENTITY。身份有利于插入用户数据，元数据表通常是静态的。当您为代码部署更新时，您不希望感到惊讶并且 IDENTITY 值与您预期的不同。

例如，您在“Languages”表中添加了一个新值，您希望 ID 为 6，但由于某种原因（开发不同步，另一个人尚未实现他们的下一个语言类型等），您的下一个身份get 是不同的，比如说 7。然后，您插入或转换一堆使用 Language ID=6 的行，这些行都失败了，因为它不存在（它在元数据表中是 7 i）。更糟糕的是，它们实际上都插入或更新，因为您认为是您的值 6 已经在 medadata 表中，并且您现在混合了两个共享相同 6 值的项目，而您的新值 7 未被使用。

我会根据您需要多少代码、需要查看它的频率来选择正确的数据类型（CHAR 很适合查看一些值，有助于记忆）。

例如，如果您只有几个组，并且您会经常查看原始数据，那么 char(1) 可能会很好：

GroupTypes table
-----------------
GroupType            char(1)    --'M'=manufacturing, 'P'=purchasing, 'S'=sales
GroupTypeDescription varchar(100)

但是，如果有许多不同的值，那么某种形式的 int (tinyint, smallint, int, bigint) 可以做到：

EmailTypes table
----------------
EmailType            smallint    --2 bytes, up to 32k different positive values
EmailTypeDescription varchar(100)
于 2009-09-04T12:20:03.917 回答
1

好吧，如果这些数字对您很重要，因为它们将在代码中，我可能不会使用 IDENTITY。

相反，只需确保使用 INT 列并将其设为主键 - 在这种情况下，您必须自己提供 ID，并且它们必须是唯一的。

于 2009-09-04T07:57:16.500 回答
1

如果数字在您的代码中是硬编码的，请不要使用身份字段。将它们硬编码在数据库中，并且它们不太容易更改，因为有人对数据库编写了糟糕的脚本。

于 2009-09-04T07:59:50.427 回答
1

我将使用标识列作为主键，也只是为了简单起见将记录插入数据库，然后使用列作为元数据类型，我称之为 LookUpType(int)，以及 LookUpId 的列（int 值在代码中）或选择列表中的值，LookUpName（字符串），如果这些值需要额外的设置，可以说使用额外的列。我个人使用了两个 extra，LookUpKey 用于层次关系， LookUpValue 用于 LookUpName 的缩写或替代值。

于 2009-09-04T08:06:48.663 回答