使用VARCHAR作为'ORPHAN'表的PRIMARY KEY

Question

我要创建一个包含3列的孤立表（与任何其他表没有任何关系）。

• Col1 - 字符串字段 - VARCHAR（32） - 包含不超过32个字符的唯一数据
• Col2 - 字符串字段 - TEXT - 包含更大的非唯一字符数据
• Col3 - 数字（布尔） - INT（1） - 0/1用于标记

我正在考虑使用Col1作为我的PRIMARY KEY。我做了一些研究，看到人们认为使用无意义的INT列作为主要关键来避免外键/存储问题是可行的方法。

然而，IMO，因为这是一个孤儿表，所以应该没关系。此外，我还是要求在Col1上放置一个INDEX。

作为旁注，我预计此表中的行数不会超过1000行。

请注意。

Answer 1

我仍然只使用INT PK并在COL1上放置一个索引。我想你可以使用COL1作为索引，如果你可以确保没有任何东西可以连接到那个表，但如果没有别的，索引将让你知道从表中添加/删除项目的顺序。我还想添加一个IsActive布尔值，这样你几乎不会删除任何东西和几乎每个表的DateCreated日期时间。

Answer 2

我看到你来自哪里，但无论如何索引第一列是有意义的。这可能是因为我习惯于擅长但是主键的初始列的有用性在调试或捕获数据时也具有顺序以及可读性。如果您使用更随机生成的数字，您仍然会搜索几百行，寻找难以区分的密钥。最后，我强烈推荐额外的一列。这非常值得。

Answer 3

每当我做任何数据库表时，我都会保留我的INT列。 我相信比较数字和字符串会更快。

所以这一切都取决于你将如何查询数据库中的信息并比较那里的字符串。

Answer 4

如果col1是真正的主键，则没有理由不使用它。特别是如果桌子那么小。

无论如何，您需要在该列上维护唯一索引，因此通过添加人工主键，您只需添加更多开销，即插入和删除操作（因为必须维护两个索引）。

除非您从真正的，非常多的其他行（以及其他表）中引用该PK，否则您应该使用业务规则的自然主要内容。

Answer 5

我还不清楚问题是什么。从答案来看，我把它推断为两个看似合理的问题：

1. 可以使用VARCHAR而不是INTEGER作为主键吗？
   • 是的，可以改用VARCHAR 在许多情况下，它是首选，特别是如果您的表预计会超过2,147,483,647记录（是的，这种情况发生）。性能方面，即使INT具有最小的速度优势，在~1000记录表上，您也不会看到它。默认情况下，指定的PK会被编入索引。一个问题是你将丢失数据库可以为你做的任何自动生成序列。
2. 是否可以将您的唯一COL1字段用作主键，而不是其他一些唯一ID字段？
   • 是的，没关系。
     拥有主键的整个概念是建立一个独特的领域。但是，你失去的可能是一些内在的理解。当其他用户想要加入该表时，更容易理解id是唯一字段，而col1（某些varchar）可能是唯一的，也可能不是唯一的。

Answer 6

在你给定的场景中，它应该没问题。如果范围确实增长，那么您始终可以引入auto_increment PK列。只需确保您的字段已编入索引且唯一。