我有一个产品表，有两个选项：
让用户输入 PK，因为有些用户可以输入条形码或不输入（在这种情况下，应用程序将允许用户自由输入任何内容，例如他自己的代码约定，如奥利奥冰淇淋 IC-O）显然，我需要添加一些验证以避免 PK 包含数千个字符等等。
使用自动增量 PK 并为“SecondaryCode”创建另一个字段，但对于用户来说，这将是主键，这里也对 SecondaryCode 进行一些验证，并且使用像 PK 这样的 SecondaryCode 感觉很奇怪。
有什么非常糟糕的理由不选择第一个选项吗？理论上是好的，而且更容易管理，但我不太愿意将一些重要的东西暴露为主键。也许我忽略了一些显而易见的东西。
PRIMARY KEY 是一个结构（在大多数情况下，这是一个包含一个单列的表达式），它唯一地标识一行。
这是服务结构，而非信息结构。服务器在连接、选择、锁定等过程中识别行时会使用它，服务器的一致性子系统在检查外键约束时也会使用它。在大多数情况下，此列的值对用户不可见。
我更喜欢您的选项 2 - 合成自动增量列作为 PRIMARY KEY，以及用户输入代码的列，可能伴随 NOT NULL 和/或 UNIQUE 约束。