Php 在MySQL表中使用字符串作为ID可以吗？

我设计了我的数据库，并使用varchar来创建唯一的名称。我制作了一个产品表，每个产品都有一个产品代码，这个代码是唯一的，不能重复，主要是我在父表中的主键。我的想法是，例如，我有一支蜡烛，蜡烛有不同的颜色，所以不同的产品，我可以通过产品代码来区分产品名称。我没有使用或将表命名为int类型的可索引id，当插入新项时，它会自动递增。我只是将唯一代码用作外键上其他表的索引器

我不知道这是否是一个好主意，我对PHP MySQL非常陌生，在将值插入不同的表时遇到了一些问题，所以我使用产品代码将它们链接起来。现在我只知道mysqli_insert_id的东西，它早就可以解决我的问题了

---

所以我可以只使用字符串的非标准行id而不是int类型的行id吗

就我个人而言，我会说使用auto inc ID。将产品代码用作ID/主键意味着您以后无法（或将更难）更改产品代码，这可能会导致问题

详细说明：

---

如果最终扩展了数据库，使产品链接到各个表，则使用产品代码作为ID意味着如果要更改产品代码，则必须更新所有表中的每个条目。使用一个不是产品代码的ID意味着您只需在一个位置（库存表）更新代码，而ID将在您加入库存表以获取产品代码时执行其余操作。

您可以这样做，但仅仅因为您可以这样做，并不意味着您应该这样做。从理论上讲，主键在数据库之外不应有任何意义。根据定义，产品代码具有数据库之外的含义

字符串ID的最大缺点是使索引（大得多）更大，这可能会影响性能

我会保持简单，使用标准的自动增量int

---

我也同意@hd1和@webnoob的答案——行id应该是常量，并且独立于它所描述的值——经典错误（在我看来）行id是美国SSN或政府分配给人或公司的任何其他唯一数字。

字符串需要解析为相等（在查询、连接等时）。所以，这里有一个性能含义。这意味着您应该尽可能避免使用它。

只要我们有关系数据库，自然键和代理键的利弊就会继续争论不休。我说：做你喜欢做的，但是如果你要使用代理，尽量确保，在可能的情况下，也有一种通过自然键唯一标识行的方法。

任何唯一的[理想情况下不改变]值，一组值都可以用作数据库中的键/主键。代理键[例如：自动递增的INT列]在mySQL中如此常见的主要原因是：

很长一段时间外键都是不可能的，[InnoDB直到最近才变得可用]，没有外键的情况下保持多个表之间的字符串键同步是一场噩梦

字符串列上的索引具有长度，并且可以比列本身短。这是为了使索引保持紧凑，但也可能导致问题。例如：

name

列中长度为5的键在name

Tom Cruise

和

Tom Clancy

上发生冲突，因为键是

Tom C

---

假设您在表上有某种形式的索引，应该不会有问题。ID可以是您想要的任何东西。在内部使用int更有效，但大多数可以在其上添加唯一索引的东西都可以用作ID。字符串类型的主键是否会使索引大小比int类型的更大？如果您有唯一的方法来标识产品，请使用它作为主键。无论如何，你都要为它建立索引。我明白了，字符串对性能有着巨大的影响，我想我必须重新思考和重构我的数据库，以便它能够容纳int索引器。是的，这是我的问题，我怎么做？如果是在飞行中，我怎么知道身份证？也许mysqli_insert_id及其对应项就是答案？我看到一篇文章，其中给出了这样做的概念，所以我刚开始问这个问题，如果我做的是对的。如果你有一个有很多表的大型数据库，那么更改产品代码意味着你必须更改不同表中的很多不同数据。使用非产品代码的ID意味着您可以在一个地方更改产品代码。我不是说你不能更新auto inc字段。@asah他说的是代理键的值。自动更新并不重要，重要的是您希望更新密钥的可能性有多大。如果你能预见这种情况的发生，那么按照建议去做就可以省去很多痛苦。@TonyHopkinson-这正是我的意思，我只是找不到合适的词语来表达：）嗯，我刚刚意识到，如果我只允许更改父表中的产品代码，我已经设计了父表中的更改，以级联到子表中，它会有问题吗？您所指的问题是更改子表上的产品代码？我可以看到它可以向上更新继承权。如果您打算允许更改产品代码，并且从头开始数据库设计，那么使用自动ID将是明智的，它将节省您的工作，而不管您有什么实现。使用产品代码意味着在更改产品代码时，任何链接到stock的表都需要更新，这与关系数据库的观点背道而驰。这是什么“理论”呢？在关系数据库理论中，主键应该是数据的一个本质上独特的方面。我不相信任何来自数据库外部的数据都有真正独特的方面（即SSN，员工子女出生的日期）。哦，我们会有一个deb吗