1

关于静态数据表设计。在表中具有静态数据，如下所示：

  • 货币（代码、名称）。行示例：USD、美元
  • 国家（代码、名称）。行示例：DE，德国
  • XXXObjectType（代码、名称、...附加属性）
  • ...

将另一个 (INTEGER) 列作为主键以便所有外键引用都使用它是否有意义？

可能的解决方案：

  1. 使用额外的 INTEGER 作为 PK 和 FK
  2. 使用代码（通常是 CHAR(N)，其中 N 很小）作为 PK 和 FK
  3. 仅当小于特定大小时才使用代码...什么大小？
  4. 其他_______

你的建议是什么？为什么？

我通常使用INT IDENTITY列，但通常短代码足以在 UI 上显示给用户，在这种情况下，查询将少一个 JOIN。

4

2 回答 2

7

这里绝对不需要 INT IDENTITY。请改用 2 位或 3 位助记符。如果您的实体没有小的唯一属性，那么您应该考虑使用合成密钥。但是货币代码和国家代码不是这样做的时候。

我曾经在一个系统上工作过，其中有人实际上有一个年份表，并且每年都有一个 YearID。而且，按照形式，2001 年是第 3 年，而 2000 年是第 4 年。这使得系统中的其他所有内容都变得更加难以理解和查询，而且毫无意义。

于 2009-06-05T12:05:55.603 回答
3

如果您使用 ID INT 或 CHAR，则在这两种情况下都会保留参照完整性。
一个 INT 有 4 个字节长，因此它的大小与 CHAR(4) 相同；如果您使用 x<4 的 CHAR(x)，您的 CHAR 键将比 INT 键短；如果您使用 CHAR(x) 其中 x>4，您的 CHAR 键将大于 INT 键；对于短键，使用 VARCHAR通常没有意义，因为后者有 2 字节的开销。无论如何，当谈论具有 500 条记录的表时，CHAR(5) 在 INT 键上的总开销仅为 500 字节，对于某些表可能有数百万条记录的数据库来说，这个值很有趣。
考虑到国家和货币（例如）的数量有限（最多几百个），你没有真正的使用 ID INT 而不是 CHAR(4) 获得收益；此外，对于最终用户来说，CHAR(4) 键更容易记住，并且可以在您必须调试/测试 Sql 和/或数据时减轻您的负担。
因此，尽管我通常对我的大多数表使用 ID INT 键，但在某些情况下，我选择使用由 CHAR 组成的 PK/FK：国家、语言、货币都属于这些情况。

于 2009-06-05T12:47:43.460 回答