概念
您误解了一些基本概念，因此而造成了困难。我们必须首先解决概念，而不是您认为的问题，因此，您的问题将消失。
自动递增的ID，当然是主键。
不，他们不是。这是一个普遍的误解。并保证了随之而来的问题。
一个
ID字段不能作为主键中英文或技术或关系的感觉。
当然，在SQL中，您可以将 任何 字段声明为
PRIMARY KEY
，但这并不能从英语，技术或关系意义上将其神奇地转换为主键。您可以将吉娃娃命名为“ Rottweiller”，但这并不能将其转换为Rottweiller，它仍然是吉娃娃。像任何一种语言一样，SQL只是执行您提供的命令，它不能理解PRIMARY KEY
为某种关系，它只是在列（或字段）上重击唯一索引。问题是，既然你已经 宣布 的
ID
是一个PRIMARY KEY
，你 认为 它作为一个主键，你可以 期望 它有一些主键的特质。除了ID 值 的唯一性，它没有任何好处。它没有主键的质量，也没有任何关系密钥的质量。它不是英语，技术或关系意义上的关键。通过将非密钥声明为密钥，您只会混淆自己，并且您将发现只有当用户抱怨表中的重复项时，才出现严重错误。
关系表必须具有 行 唯一性
字段
PRIMARY KEY上的A
ID不提供 行
唯一性。因此，它不是包含行的关系表，如果不是，则它是包含记录的文件。它不具有关系数据库中的表所具有的任何完整性，功能（在此阶段，您仅会意识到联接功能）或速度。
执行 此代码 （MS SQL
2008）并向自己证明。请不要简单地阅读并理解它，然后继续阅读本答案的其余部分， 必须在进一步阅读之前执行此代码 。具有治疗价值。
CREATE TABLE dumb_file ( id INT NOT NULL IDENTITY PRIMARY KEY, name_first CHAr(30) NOT NULL, name_last CHAr(30) NOT NULL ) INSERT dumb_file VALUES ( "Mickey", "Mouse" ) -- succeeds INSERT dumb_file VALUES ( "Mickey", "Mouse" ) -- succeeds, but not intended INSERT dumb_file VALUES ( "Mickey", "Mouse" ) -- succeeds, but not intended SELECt * FROM dumb_file
请注意，您有重复的 行 。关系表必须具有唯一的 行 。进一步证明您没有关系表或任何关系表。
请注意，在您的报告中，唯一的唯一
ID字段是没有用户关心，没有用户看到的字段，因为它不是数据，这是一些非常愚蠢的“老师”告诉您在每个字段中输入的内容。文件。您具有
记录 唯一性，但没有 行 唯一性。
就数据而言（实际数据减去多余的加法），数据可以不存在字段
name_last而
name_first存在
ID。一个人的名字和姓氏没有在其额头上刻印的ID。
如果使用的是
AUTOINCREMENT.
没有关系功能的记录归档系统，那么肯定使您感到困惑，这很有用，在插入记录时不必编写增量代码。但是，如果您要实现一个关系数据库，则它根本没有用，因为您将永远不会使用它。大多数人从未使用过SQL中的许多功能。
纠正措施
那么，如何将具有重复行的dumb_file升级，提升为关系表，以便获得关系表的某些质量和好处？这需要三个步骤。
您需要了解按键
- 并且由于我们已经从1970年代的ISAM文件发展到了 关系模型 ，因此您需要了解 关系密钥 。也就是说，如果您希望获得关系数据库的好处（完整性，功能，速度）。
EF Cood博士在其 RM 中宣称：
密钥由数据组成
和
表中的行必须唯一
您的“密钥”不是由数据组成的。这是由于您感染了“老师”疾病而引起的一些其他非数据寄生虫。就这样认识到这一点，并让自己拥有上帝赋予您的全部心理能力（请注意，我不要求您以孤立，零散或抽象的方式思考，数据库中的所有元素必须相互整合）。
仅从数据中 构成真实密钥。在这种情况下，只有一个可能的密钥：
(name_last, name_first).
- 尝试以下代码 ，对数据 声明 唯一约束：
CREATE TABLE dumb_table ( id INT NOT NULL IDENTITY PRIMARY KEY, name_first CHAr(30) NOT NULL, name_last CHAr(30) NOT NULL ConSTRAINT UK UNIQUE ( name_last, name_first ) )INSERT dumb_table VALUES ( "Mickey", "Mouse" ) -- succeedsINSERT dumb_table VALUES ( "Mickey", "Mouse" ) -- fails, as intendedINSERT dumb_table VALUES ( "Minnie", "Mouse" ) -- succeedsSELECt * FROM dumb_table
现在我们有了 行的唯一性
。这是大多数人发生的顺序：他们创建了一个允许重复的文件；他们不知道为什么骗子出现在下拉菜单中；用户尖叫；他们调整文件并添加索引以防止重复；他们转到下一个错误修复程序。（他们可能正确或错误地这样做，那是另一回事。）
- 第二级。对于有思想的人，他们的想法超出了它的解决范围。由于我们现在具有行唯一性，因此以天堂的名义命名的目的是该
ID
字段，为什么我们还要拥有它？哦，因为吉娃娃叫罗蒂，我们害怕碰它。
它是a的声明
PRIMARY KEY是错误的，但是仍然存在，从而引起混乱和错误的期望。此时唯一的真正密钥是，
(name_last,name_fist),并且它是 备用密钥 。
因此，该
ID领域是完全多余的。支持它的索引也是如此；愚蠢的人也如此
AUTOINCREMENT; 错误的声明它是一个
PRIMARY KEY;
您可能对它的任何期望都是错误的。
因此，请删除多余的
ID字段。 试试这个代码 ：
CREATE TABLE honest_table ( name_first CHAr(30) NOT NULL, name_last CHAr(30) NOT NULL ConSTRAINT PK PRIMARY KEY ( name_last, name_first ) ) INSERT honest_table VALUES ( "Mickey", "Mouse" ) -- succeeds INSERT honest_table VALUES ( "Mickey", "Mouse" ) -- fails, as intended INSERT honest_table VALUES ( "Minnie", "Mouse" ) -- succeeds SELECt * FROM honest_table
工作正常，按预期工作，没有多余的字段和索引。
请记住这一点，并每次正确执行。
假老师
根据建议，在这些结束时间中，我们将有很多。请注意，
ID凭借这篇文章中的详细证据，传播列的“老师” 根本不了解 关系模型
或关系数据库。尤其是那些为此写书的人。
事实证明，它们陷于1970年前的ISAM技术中。他们所了解的就是他们所能教的。他们使用SQL数据库容器来简化访问，恢复，备份等操作，但是内容是纯记录归档系统，没有关系完整性，功能或速度。在非洲，这是严重的欺诈行为。
ID当然，除了领域之外，还有一些关键的关系或非关键概念的项目，这些项目使我得出这样一个严肃的结论。这些其他项目不在本文的讨论范围之内。
一对特定的白痴目前正对“第一范式”进行攻击。他们属于庇护所。
回答
现在剩下的问题了。
有没有一种方法可以创建关系表而不丢失自动增量功能？
那是一个自相矛盾的句子。我相信你会从我的解释明白，关系表 也没有必要 对
AUTOINCREMENT“特色”;
如果文件包含
AUTOINCREMENT，则它不是关系表。
AUTOINCREMENT仅对一件事有好处：当且仅当您想在SQL数据库容器中创建Excel电子表格时，顶部要填充名称为
A,
B,and的字段
C,，并在左侧记录数字。在数据库术语，即 结果 是SELECt，数据的平面视图，也就是 不 与 源
数据的，这是组织的（归一化）。
另一个可能的（但不推荐）的解决方案可能是在第一个表中还有另一个主键，它是用户的用户名，当然不带自动增量语句。 这是不可避免的吗？
在技术工作中，我们不在乎首选项，因为这是主观的，并且会随时更改。我们关心技术的正确性，因为这是客观的，并且不会改变。
是的，这是不可避免的。因为这只是时间问题；错误数量；“不能做”的数量；用户的尖叫声，直到您面对事实，克服了错误的声明并意识到：
确保用户 行 唯一，user_names唯一的唯一方法是对其声明
UNIQUE
约束并摆脱
user_id
或id
在用户文件中促进
user_name
以PRIMARY KEY
是的，因为这样就消除了您对第三张桌子的整个问题，而并非巧合。
第三张表是 关联表 。唯一需要的键（主键）是两个父主键的组合。这样可以确保各 行的 唯一性，这些 行 由其键而不是其键标识
IDs.
我警告您，因为教给您实现
ID字段错误的同一个“老师”教
ID了关联表中实现字段的错误，与普通表一样，该表是多余的，毫无用处，介绍了重复，并引起混乱。而且这是多余的，因为提供的两个键已经在那儿了，盯着我们。
由于他们不了解 RM 或关系术语，因此将关联表称为“链接”或“映射”表。如果它们具有
ID字段，则实际上是文件。
查找表
ID领域是特别 愚蠢的事 了查找或参考表。它们中的大多数都有可识别的代码，因此不需要枚举其中的代码列表，因为这些代码是（应该是）唯一的。
此外，将子表中的代码作为FK放在一起是一件好事：该代码更有意义，并且通常可以节省不必要的联接：
SELECT ... FROM child_table-- not the lookup table WHERe gender_pre = "M" -- FK in the child, PK in the lookup
代替：
SELECt ... FROM child_table WHERe gender_id = 6 -- meaningless to the maintainer
或更糟的是：
SELECt ... FROM child_table C -- that you are trying to determine JOIN lookup_table L ON C.gender_id = L.gender_id WHERe L.gender_pre = "M" -- meaningful, known
请注意，这是一件谁都无法回避：你需要查找代码的唯一性 和 独特性的描述。这是防止两列中的 每 列重复的唯一方法：
CREATE TABLE gender ( gender_pre CHAr(2) NOT NULL, name CHAr(30) NOT NULL ConSTRAINT PK PRIMARY KEY ( gender_pre ) ConSTRAINT AK UNIQUE ( name ) )
完整的例子
从问题的详细信息中，我怀疑您有SQL语法和FK定义问题，因此，我将以您需要的整个解决方案为例（因为您没有提供文件定义）：
CREATE TABLE user ( -- Typical Identifying Table user_name CHAr(16) NOT NULL, -- Short PK name_first CHAr(30) NOT NULL, -- Alt Key.1 name_last CHAr(30) NOT NULL, -- Alt Key.2 birth_date DATE NOT NULL -- Alt Key.3 ConSTRAINT PK -- unique user_name PRIMARY KEY ( user_name ) ConSTRAINT AK -- unique person identification PRIMARY KEY ( name_last, name_first, birth_date ) ) CREATE TABLE sport ( -- Typical Lookup Table sport_pre CHAr(4) NOT NULL, -- PK Short pre name CHAr(30) NOT NULL -- AK ConSTRAINT PK PRIMARY KEY ( sport_pre ) ConSTRAINT AK PRIMARY KEY ( name ) ) CREATE TABLE user_sport (-- Typical Associative Table user_name CHAr(16) NOT NULL, -- PK.1, FK sport_pre CHAr(4) NOT NULL, -- PK.2, FK start_date DATE NOT NULL ConSTRAINT PK PRIMARY KEY ( user_name, sport_pre ) ConSTRAINT user_plays_sport_fk FOREIGN KEY ( user_name ) REFERENCES user ( user_name ) ConSTRAINT sport_occupies_user_fk FOREIGN KEY ( sport_pre ) REFERENCES sport ( sport_pre ) )
在那里，
PRIMARY KEY声明是诚实的，它是主键；否
ID;否
AUTOINCREMENT;否多余的索引；没有重复的 行 ;
没有错误的期望；没有相应的问题。
资料模型
这是带有定义的数据模型。
用户运动数据模型示例
如果您不习惯该符号，请注意，实线与虚线，方格与圆角之间的每一个小滴答，刻痕和记号，都意味着非常具体。请参阅 IDEF1X表示法 。
一张图片胜过千言万语; 在这种情况下，标准投诉图片的价值不止于此；不好的东西不值得用来画纸。
请仔细检查动词短语，它们包含一组谓词。其余谓词可以直接从模型中确定。如果不清楚，请询问。
