如果我只用三列创建了一个如下表所示的表：
column1 - column2 - column3 名称 - 公司 - 颜色
这是数据库表规划中的不良做法，因为它没有带有自动递增数字ID的主键吗？
答案 0 :(得分：4)
我创建的几乎所有表都有一个合成的，数字的，自动递增的（标识/串行）主键。以下是我这样做的原因：
所以，在大多数情况下，我会说这种方法是一种很好的做法。
这不是糟糕的练习吗？不必要。我保持一致。如果您有一个恰好是字符串的自然主键（例如电子邮件地址，作为一种可能性），那么请使用它。如果您使用引用表来验证字符串的值，那很好。去吧。请记住，定义外键，理解插入顺序以及获得有效索引是一种好习惯 - 合成数字键有助于实现这些目标。
答案 1 :(得分：2)
这是火焰战争的领域，这就是为什么我认为这个问题最终会被关闭的原因。更糟糕的是，一些注意事项取决于您的数据库结构但基本问题包括访问与自然主键以及有关RDBMS中表格布局的细节。
然而，我想讨论争议的双方，并讨论每个问题中的一些问题。我个人在使用PostgreSQL时，我更喜欢使用自然主键，并且通常添加数字辅助键以使连接更容易。
摘要中的自然与合成主键
一般来说，我发现自然主键在语义上更清洁。因此，PRIMARY KEY指定部分地作为关于什么在功能上依赖于什么的文件。在给定的表格中，这可以使长期维护变得更加容易，特别是如果你正在为很好的桌子拍摄。
然而问题是，通常自然主键跨越列，并且随着需求的改变，表可以改变，使得主键可以改变。这使得变更管理成为一个大问题，特别是随着表的增长，人们常常需要围绕该问题进行抽象层，这意味着第二个自动增量字段用于连接。
访问与数据搜索
在PostgreSQL中，not null和唯一约束与主键的组合实际上没有区别，所以这很有效。然而，到处都不是这种情况。在使用InnoDB的MySQL中，该表是围绕主键的索引，因此主键查找是以其他查找为代价进行优化的。
出于这个原因，在这样的数据库系统中，您会发现使代理键成为主要内容并找到另一种记录自然主键的方法会带来严重的性能优势。
注意，其他数据库系统可能允许围绕主键以外的索引使用面向索引的表，这会导致这种考虑方式不同。
对于单列表（用于有效地强制执行db本身不支持这种情况的枚举类型）但是，我发现添加额外的数字主键绝对没有价值。
<强>结论
这是否是不好的做法取决于您正在做什么以及您正在使用的数据库。它不一定是坏事，但它可以。这两种方法都存在问题，它们在不同的场景和不同的数据库系统中发挥着不同的作用。但希望上述内容有助于介绍这些问题。
答案 2 :(得分：-1)
在大型项目中，我们始终使用 GUID （通用唯一标识符）这是一个128位整数，用于标识资源。我记得在某处读到这是“学术”的正确方法。它还会产生很多关于指定对象的信息，如日期，生产线，显示位置等。
但当然这取决于你在做什么......我确信一个简单的自动增加的int将完成这项工作，但GUID在统计上更安全和专业。