假设您有 2 个名为 John Doe 的客户。您将它们插入表中，并为它们分配一个 ID 为 34 的代理主键，另一个为 237 的代理主键。一位顾客走进商店。说“嗨，我是 John Doe，我是来买东西的”。您输入“John Doe”，然后在屏幕上调出他的帐户，您会看到 2 个选项 - John Doe 34 和 John Doe 237。您看着客户并问“您是 John Doe 34 还是 237？”。客户认为你疯了，然后走开了...... ID 不能识别实体，它是 50 年前磁带有地址指针时的思想遗迹......
您的问题是业务问题，而不是数据库问题。“唯一标识符”或您的密钥应该是企业用来区分客户的密钥。有些可能使用用户名，有些可能使用电子邮件，有些可能使用 SSN，有些可能使用视网膜扫描。数据库模式是业务现实的模型，因此，它应该遵循现实世界中使用的键。
分配代理键（例如 IDENTITY 或 GUID）对您没有多大帮助，因为您仍然无法将一个客户与另一个客户区分开来，因为您无法从客户本身中提取该属性，并且名称通常是不够。如果一个客户走进办公室并且有另外 4 个同名客户，你会怎么做？
问题提到收集的数据是“客户的姓名、地址、出生日期、当前手机号码”。如果这就是您在“现实世界”中区分客户的全部内容，那就是您的关键。也许只是名字和姓氏，也许是名字和姓氏+地址，也许只是手机号码......
至于付款，同样，这个问题没有提供足够的信息让你给出答案。有哪些付款方式可用？现金？支票？信用卡？只能电汇吗？客户可以通过多种付款方式和多种付款方式付款吗？再说一次 - 无论企业使用什么来区分付款，您的密钥都是。
高温高压