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

自动递增的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