引用SQL Server中2列主键的外键_Sql_Sql Server 2005_Foreign Key Relationship

引用SQL Server中2列主键的外键

sql sql-server-2005

引用SQL Server中2列主键的外键,sql,sql-server-2005,foreign-key-relationship,Sql,Sql Server 2005,Foreign Key Relationship,这个问题与SQL Server 2005非常相似，但对于SQL Server 2005：我的数据库中有两个表： --'#' denotes the primary key [Libraries] #ID #Application Name 1 MyApp Title 1 2 MyApp Title 2 [Content] #ID Application LibraryID Content 10 MyApp 1

这个问题与SQL Server 2005非常相似，但对于SQL Server 2005：

我的数据库中有两个表：

--'#' denotes the primary key
[Libraries]
#ID   #Application  Name
 1     MyApp        Title 1
 2     MyApp        Title 2


[Content]
#ID   Application  LibraryID  Content
 10    MyApp       1          xxx
 11    MyApp       1          yyy

（数据库显然要复杂得多，使用这个双键是有意义的）

每个库都由其唯一的ID和应用程序名称标识。我试图确保每个内容都正确地引用了现有库

创建约束时（使用向导），如下所示：

我有以下错误：

表“Libraries”中的列不匹配现有主键或唯一约束

你知道发生了什么事吗？如果可以使用SQL Server呢？（我根本无法修改[Library]表）

非常感谢你的帮助

当然，可以创建与复合主键（多个列）的外键关系。你没有向我们展示你用来尝试建立这种关系的陈述——应该是这样的：

ALTER TABLE dbo.Content
   ADD CONSTRAINT FK_Content_Libraries
   FOREIGN KEY(LibraryID, Application)
   REFERENCES dbo.Libraries(ID, Application)

这就是你用的吗？？如果

（ID，Application）

确实是

dbo.Libraries

上的主键，那么这个语句肯定会起作用

Luk：只是想检查一下-你能在数据库中运行这个语句并报告输出是什么吗

SELECT
    tc.TABLE_NAME,
    tc.CONSTRAINT_NAME, 
    ccu.COLUMN_NAME
FROM 
    INFORMATION_SCHEMA.TABLE_CONSTRAINTS tc
INNER JOIN 
    INFORMATION_SCHEMA.CONSTRAINT_COLUMN_USAGE ccu 
      ON ccu.TABLE_NAME = tc.TABLE_NAME AND ccu.CONSTRAINT_NAME = tc.CONSTRAINT_NAME
WHERE
    tc.TABLE_NAME IN ('Libraries', 'Content')

内容

表可能有多个重复的

应用程序

值，无法映射到

库

。是否可以从

库

主键索引中删除

应用程序

列，并将其添加为唯一键索引？

我也遇到了同样的问题，我想我找到了解决方案

如果表

库中的字段应用程序有一个外键引用另一个表中的字段（我敢打赌名为应用程序），那么表库中的字段应用程序也必须有一个外键指向表应用程序
在这之后，您就可以编写外键了
请原谅我的英语不好，如果我错了，请原谅。
请注意，字段的顺序必须相同。如果正在引用的主键被指定为（应用程序，ID），则外键必须引用（应用程序，ID）而不是（ID，应用程序），因为它们被视为两个不同的键。
键是“列的顺序应该相同”
例如：
create Table A (
    A_ID char(3) primary key,
    A_name char(10) primary key,
    A_desc desc char(50)
)

create Table B (
    B_ID char(3) primary key,
    B_A_ID char(3),
    B_A_Name char(10),
    constraint [Fk_B_01] foreign key (B_A_ID,B_A_Name) references A(A_ID,A_Name)
)

表A上的列顺序应该是-->A_ID
然后是A_Name
；定义外键也应遵循相同的顺序。
是的，对于应用程序
可能重复，但这并不要求是唯一的。这对（LibraryID，Application）
甚至可以有多个值-这不是内容
表上的主键-而是库
表上的主键！好的，那么当您从与库上的（ID、应用程序）不对应的内容中获取（LibraryID、应用程序）时会发生什么呢？到目前为止，没有强制执行的约束。如果OP不想改变当前的结构，我建议他尝试在（LibraryID，Application）上创建一个唯一的键索引，看看是否可以成功创建它。只有这样，才能再次尝试创建关系。不幸的是，我根本无法触摸库。这两个表甚至应该具有1-1关系，因为我无法向库添加新列。你是对的，那里需要一个唯一的索引（但这并没有解决问题）我是否错误地认为我只能引用外键中的列？Luk：你可以引用FK中的两列。是否已检查内容中的所有行是否都可以映射到库？（一个简单的左连接将决定您是否可以这样做）我当时正在直接使用UI，但使用您的语法会引发以下错误：“在引用的表'dbo.Libraries'中没有与外键中的引用列列表匹配的主键或候选键……在这种情况下，这对键（Id，Application）不是库表上的主键。您只能引用父表上的主键，或者引用作为唯一索引一部分的列（或一组列）。检查库表！这也是我的第一个想法，但SQL脚本指定创建表[Libraries]（…`CONSTRAINT[PK\u sf\u Libraries]主键聚集（[Application]ASC，[ID]ASC）与[PRIMARY]`（很抱歉在这里转储所有SQL）@Luk:添加了一条语句，您可以在您的数据库上为我运行-只是为了检查一下…..嗯，有人考虑过吗？”Russell的理论会在下面的“2014年3月18日14:43”回答中出现吗？我知道Luk说他是在“新数据库”中使用它的，但是如果他“正在使用UI”（相对于修改自动生成的脚本），他承认至少在他最初的FK添加尝试中这样做过一次，那么他也很有可能在“新数据库”中这样做，因此很有可能在“新数据库”中，他意外地获得了一致的列顺序（创建表中的PK def和Alter表中的FK def）。我怀疑这也是问题所在，特别是因为他在主键def中首先列出了“应用程序”（“主键聚集（[Application]ASC，[ID]）ASC），但在他的作品中，他的两个例子中都是“ID”。我对其他人（包括500多人（小指到嘴唇）表示“marc_'s”感到惊讶在你之前的4年8个月里指出了这一点。哦，我的上帝，我花了几个小时试图弄明白这一点，结果证明这就是答案。谢谢你！！！！
create Table A (
    A_ID char(3) primary key,
    A_name char(10) primary key,
    A_desc desc char(50)
)

create Table B (
    B_ID char(3) primary key,
    B_A_ID char(3),
    B_A_Name char(10),
    constraint [Fk_B_01] foreign key (B_A_ID,B_A_Name) references A(A_ID,A_Name)
)