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

发布时间：2021-03-14 16:34:49 所属栏目：MySql教程来源：网络整理

导读：副标题#e# 我有2个表,都有自己的自动递增ID,这当然是主键. 当我想创建第3个表来建立这两个表之间的关系时,我总是有一个错误. 第一个是关于你只能有一个自动递增的列,第二个是当我从那些2中删除auto_increment语句时发生的,因此sql不允许我将它们作为外键,因

副标题[/!--empirenews.page--]

我有2个表,都有自己的自动递增ID,这当然是主键.

当我想创建第3个表来建立这两个表之间的关系时,我总是有一个错误.

第一个是关于你只能有一个自动递增的列,第二个是当我从那些2中删除auto_increment语句时发生的,因此sql不允许我将它们作为外键,因为类型匹配失败.

有没有办法可以创建关系表而不会丢失自动增量功能？

另一种可能的(但不是优选的)解决方案可能是第一个表中有另一个主键,当然是用户的用户名,而不是自动增量语句.这是不可避免的吗？

提前致谢.

最佳答案概念

你误解了一些基本概念,并且由此产生了困难.我们必须首先解决这些概念,而不是你所认识到的问题,因此,你的问题就会消失.

auto incremented IDs,which are of course primary keys.

不,他们不是.这是一种常见的误解.并且保证问题随之而来.

ID字段不能是英语或技术或关系意义上的主键.

>当然,在SQL中,您可以将任何字段声明为PRIMARY KEY,但这并不会将其神奇地转换为英语,技术或关系意义上的主键.你可以将奇瓦瓦命名为“Rottweiller”,但这并没有将它变成罗威威尔,它仍然是奇瓦瓦.像任何语言一样,SQL只是执行你给它的命令,它不理解PRIMARY KEY意味着什么是关系,它只是在列(或字段)上敲击一个唯一索引.
>问题是,由于您已将ID声明为PRIMARY KEY,因此您将其视为主键,并且您可能期望它具有主键的某些特性.除了ID值的唯一性之外,它没有任何好处.它没有主键的任何特性,也没有任何关系密钥.它不是英语,技术或关系意义上的关键.通过声明非密钥成为密钥,您只会混淆自己,并且只有当用户抱怨表中的重复时才会发现存在严重错误.

关系表必须具有行唯一性

ID字段上的PRIMARY KEY不提供行唯一性.因此,它不是包含行的Relational表,如果不是,则它是包含记录的文件.它没有任何完整性或功能(在此阶段,您将只知道连接功率)或速度,即Relational数据库中的表具有.

执行this code(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",but not intended

    SELECT * FROM dumb_file

请注意,您有重复的行.关系表需要具有唯一的行.进一步证明您没有关系表或任何一个关系表.

请注意,在您的报告中,唯一唯一的是ID字段,没有用户关心,没有用户看到,因为它不是数据,一些非常愚蠢的“老师”告诉您放入的一些额外的废话每个文件.您具有记录唯一性,但不具有行唯一性.

就数据而言(实际数据减去无关的添加),数据name_last和name_first可以在没有ID字段的情况下存在.一个人的名字和姓氏没有在他们的额头上盖上身份证.

你正在使用的第二件事就是AUTOINCREMENT.如果您正在实现一个没有关系功能的记录文件系统,当然,这很有用,您不必在插入记录时对增量进行编码.但是,如果您正在实现一个关系数据库,它根本没有用处,因为您永远不会使用它. SQL中有许多功能,大多数人从不使用.

纠正措施

那么如何将充满重复行的dumb_file升级,提升到Relational表,以获得Relational表的一些特性和优点？这有三个步骤.

>你需要了解Keys

>既然我们已经从1970年代的ISAM文件发展到关系模型,你需要了解关系密钥.也就是说,如果您希望获得关系数据库的好处(完整性,功能,速度).

E F Coo??d博士在他的RM中宣称：

a key is made up from the data

和

the rows in a table must be unique

您的“密钥”不是由数据组成的.这是一些额外的非数据寄生虫,由您感染“老师”的疾病引起.认识到这一点,让自己拥有上帝给你的全部心智能力(注意我不要求你以孤立或零碎或抽象的方式思考,数据库中的所有元素必须相互整合).从数据中组成一个真正的密钥,并且只从数据中组成.在这种情况下,只有一个可能的密钥：(name_last,name_first).
> Try this code,声明对数据的唯一约束：

     CREATE TABLE dumb_table (
        id         INT      NOT NULL  IDENTITY  PRIMARY KEY,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

现在我们有行唯一性.这是大多数人发生的序列：他们创建一个允许欺骗的文件;他们不知道为什么欺骗会出现在下拉中;用户尖叫;他们调整文件并添加索引以防止欺骗;他们进入下一个bug修复. (他们可能正确或不正确,这是一个不同的故事.)
>第二级.思考那些超越修复的人 – 它.既然我们现在有行唯一性,那么天堂的名字是ID字段的目的,为什么我们甚至拥有它？哦,因为奇瓦瓦被命名为Rotty,我们不敢触摸它.

它是PRIMARY KEY的声明是错误的,但它仍然存在,导致混淆和错误的期望.唯一真正的Key是(name_last,name_fist),此时它是一个备用键.

因此ID字段完全是多余的;支持它的索引也是如此;愚蠢的AUTOINCREMENT也是如此;虚假声明它是一个主要的关键;你对它的任何期望都是错误的.

因此,删除多余的ID字段. Try this code：

    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",as intended
    INSERT honest_table VALUES ( "Minnie","Mouse" )  -- succeeds

    SELECT * FROM honest_table

工作正常,按预期工作,没有无关的字段和索引.

请记住这一点,并且每次都做得对.

假教师

在这些结束时间,按照建议,我们将拥有其中许多.请注意,根据本文中的详细证据,传播ID列的“教师”根本不理解关系模型或关系数据库.特别是那些写书的人.

（编辑：常州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

1/5

尾页