SQL：使用2个不同的auto_increment创建关系表?mysql

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

自动递增的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 Coo​​d博士在其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" )  -- succeeds
INSERT dumb_table VALUES ( "Mickey", "Mouse" )  -- fails, as intended
INSERT dumb_table VALUES ( "Minnie", "Mouse" )  -- succeeds

SELECT * 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_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表示法。

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

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