概念

您误解了一些基本概念，因此而造成了困难。我们必须首先解决概念，而不是您认为的问题，因此，您的问题将消失。

自动递增的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升级，提升为关系表，以便获得关系表的某些质量和好处？这需要三个步骤。

1. 您需要了解按键

   • 并且由于我们已经从1970年代的ISAM文件发展到了 关系模型 ，因此您需要了解 关系密钥 。也就是说，如果您希望获得关系数据库的好处（完整性，功能，速度）。

EF Coo​​d博士在其 RM 中宣称：

密钥由数据组成

和

表中的行必须唯一

您的“密钥”不是由数据组成的。这是由于您感染了“老师”疾病而引起的一些其他非数据寄生虫。就这样认识到这一点，并让自己拥有上帝赋予您的全部心理能力（请注意，我不要求您以孤立，零散或抽象的方式思考，数据库中的所有元素必须相互整合）。
仅从数据中 构成真实密钥。在这种情况下，只有一个可能的密钥：(name_last, name_first).

1. 尝试以下代码 ，对数据 声明 唯一约束：

        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" )  -- succeeds
   INSERT dumb_table VALUES ( "Mickey", "Mouse" )  -- fails, as intended
   INSERT dumb_table VALUES ( "Minnie", "Mouse" )  -- succeeds
   
   SELECT * FROM dumb_table
   

现在我们有了 行的唯一性
。这是大多数人发生的顺序：他们创建了一个允许重复的文件；他们不知道为什么骗子出现在下拉菜单中；用户尖叫；他们调整文件并添加索引以防止重复；他们转到下一个错误修复程序。（他们可能正确或错误地这样做，那是另一回事。）

1. 第二级。对于有思想的人，他们的想法超出了它的解决范围。由于我们现在具有行唯一性，因此以天堂的名义命名的目的是该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_code = "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_code = "M"  -- meaningful, known

请注意，这是一件谁都无法回避：你需要查找代码的唯一性 和 独特性的描述。这是防止两列中的 每 列重复的唯一方法：

    CREATE TABLE gender (
        gender_code  CHAR(2)  NOT NULL,
        name         CHAR(30) NOT NULL

        CONSTRAINT PK 
            PRIMARY KEY ( gender_code )

        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_code  CHAR(4)  NOT NULL,    -- PK Short code
        name        CHAR(30) NOT NULL     -- AK

        CONSTRAINT PK 
            PRIMARY KEY ( sport_code )

        CONSTRAINT AK 
            PRIMARY KEY ( name )
        )

    CREATE TABLE user_sport (           -- Typical Associative Table
        user_name  CHAR(16) NOT NULL,   -- PK.1, FK
        sport_code CHAR(4)  NOT NULL,   -- PK.2, FK
        start_date DATE     NOT NULL

        CONSTRAINT PK 
            PRIMARY KEY ( user_name, sport_code )

        CONSTRAINT user_plays_sport_fk
            FOREIGN KEY     ( user_name )
            REFERENCES user ( user_name )

        CONSTRAINT sport_occupies_user_fk
            FOREIGN KEY      ( sport_code )
            REFERENCES sport ( sport_code )
        )

在那里，PRIMARY KEY声明是诚实的，它是主键；否ID;否AUTOINCREMENT;否多余的索引；没有重复的 行 ;
没有错误的期望；没有相应的问题。

资料模型

这是带有定义的数据模型。

• 用户运动数据模型示例

• 如果您不习惯该符号，请注意，实线与虚线，方格与圆角之间的每一个小滴答，刻痕和记号，都意味着非常具体。请参阅 IDEF1X表示法 。

• 一张图片胜过千言万语; 在这种情况下，标准投诉图片的价值不止于此；不好的东西不值得用来画纸。

• 请仔细检查动词短语，它们包含一组谓词。其余谓词可以直接从模型中确定。如果不清楚，请询问。