求助sqlsever高手如何创建外键并约束！分不是问题

--主键约束是：例如，s表的ID就是一个示例。
altertablesaddconstraintPK_S_Idprimarykey(id);--外键约束为：例如s表中的ID就是主键。
,score是子表sid作为外键。

sqlserver中能用主属性作为外码嘛?

主键和外键最重要的是保证数据的完整性和一致性。
主键是该表的标识字段，并且是唯一的非空字段。
外键描述了与其他表的关系。
有了这两个限制，数据库表就可以有机地整合在一起了。
主键应该相对理解。
它可以是组合或单个字段，可以根据其过滤掉唯一记录。
外键可以存在也可以不存在，这主要取决于业务需求。
如果不设置，一般对编程没有影响，但通过适当的数据输入，将不会对输入的数据执行“引用完整性”检查。

SQL3个表之间的连接(sqlserver三张表相连接)

选择

（检查第一个表、字段等中的数据）

来自

关系表

加入

第一个表

位于

关系表。
外键

=

第一个表。
主键

加入

第二个表

上

关系表。
外键

=

第二个表。
主键

和你写的一样。
它应该如下所示：

选择

（检查字段）

来自

第三个表

加入

第一个表

位于

第三个表.u_id

=

第一个表u_id

加入

第二表格

位于

第三个table.w_id

=

第二个table.w_id

sqlserver中，外键必须对应别的表的主键吗？

在SQLServer中，外键不一定与其他表的主键匹配。
这个问题在计算机设计中很常见，但并不是绝对必要的。
假设有两个表：dc_standard和dc_soil。
dc_standard表包含id字段，但该字段不是主键。
dc_soil表中有一个dc_standard_id字段，应该与dc_standard表的id字段关联。
解决这个问题的策略是将dc_standard表中的id字段设置为唯一键。
具体步骤如下：1.登录SQLServer管理工具。
2.导航到dc_standard表所在的数据库。
3.右键单击​​dc_standard表并选择“修改表”。
4.打开表的属性窗口，转到“列”选项卡，选择id字段，右键单击并选择“属性”。
5.启用id字段属性窗口中的“唯一性”选项，以保证id字段的唯一性。
6.确认更改并保存。
完成id字段的唯一性设置后，可以将dc_standard_id字段设置为dc_soil表中的外键，并与dc_standard表的id字段关联起来。
此操作可确保数据的完整性和一致性。
综上所述，外键的设计比较灵活，不需要局限于其他表中对应的主键。
只需要保证数据实体之间的关系得到满足，满足数据库设计的业务需求即可。

SQL数据库中的主键与外键介绍

1.什么是主键和外键：关系数据库中的一条记录有几个属性。
如果某组属性（注意是一组）可以唯一标识一条记录，那么该组属性就可以成为主键。
例如：学生表（学生代码、姓名、性别、班级）每个学生的学号都是唯一的。
学号是用户表的主键（用户名、密码、登录级别）。
用户名是计算机的主要关键记录（卡号、学号）。
，姓名）。
计算机记录表中没有单一的属性来唯一标识一条记录，代码号和学生姓名的组合可以唯一标识一条记录，因此属性组代码和学生姓名是主键。
计算机记录表中的序列号不是笔录的主键。
，但是就像学生表中的主键对应着学生表中的学号和学号一样。
是学生表的主键，那么班级表的学生人数就称为学生表的外键。
定义主键和外键主要是为了维护关系数据库的完整性。
主键是可以标识一条记录的唯一标识符。
例如：一条记录​​包括身份证号、姓名、年龄。
ID号码是可以识别您身份的唯一号码。
其他可能是重复的。
因此，身份证号码是主键。
外键用于链接到其他表。
这是一个可以标识另一个表的记录的字段，用于维护数据的一致性。
例如，如果A表中的某个字段是B表的主键，那么它可以是A表的外键。
2.主键、外键和索引之间的区别。
主键、外键和索引有什么区别？定义：唯一标识一条记录。
不允许留空。
一个表的外键是另一表的主键。
值，但它可以有空值。
作用：用于保证数据的完整性。
用于与其他板建立连接。
用于提高查询排序速度。
Number：只能有一个主键。
外键。
一个表可以有多个唯一索引。
非聚集索引有什么区别？聚集索引必须是唯一的。
但唯一索引不一定是聚集索引。
聚集索引将数据直接存储在索引页中，而非聚集索引将索引存储在索引页中，并且这些索引指向专门的数据页上的数据。
3.数据库中主键和外键的设计原则主键和外键是将多个表组织成有效的关系数据库的粘合剂。
主键和外键的设计对物理数据库的性能和可用性具有决定性的影响。
数据库模式必须从理论逻辑设计转换为实际物理设计。
主键的结构外键是这个设计过程的关键。
当设计的数据库在生产环境中使用时，修改这些键将是困难的，因此在开发阶段设计主键和外键是必要且值得的。
主键：关系数据库依赖于主键——它们是数据库物理模式的基础。
主键在物理层面只有两个用途：1.唯一标识一行。
2.是一个可以被外键有效引用的对象。
基于以上两种用途，我在物理层面设计万能钥匙时遵循以下一些原则：1、万能钥匙对用户来说应该是无意义的。
如果用户在连接表中看到代表多对多关系的数据并抱怨该数据很少被使用，则证明其主键设计得很好。
2、主键应该是唯一的列，以提高连接和过滤操作的效率。
注意：使用合成密钥的人经常为自己辩护有两个原因，这两个原因都是错误的。
一是主键必须有实际意义。
然而，让主键有意义只是提供了人为破坏数据库的便利。
第二个是，您可以使用此方法在描述多对多关系的连接表中使用两个外键作为主键。
我也反对这种方法，因为：复合主键通常会导致错误的外键。
即当连接表成为另一个辅助表的主表时，并通过上述方式第二种方法成为该表主键的一部分。
但是，该表可以成为其他辅助表的主表，并且其主键可以成为其他辅助表主键的一部分。
从站稍后将编译该表，其主键将包含更多列。
3.切勿更新主键。
事实上，由于主键除了唯一标识一行之外没有其他用途，因此没有理由更新它。
如果需要更新主密钥，就违反了主密钥必须对用户无意义的原则。
注意：此原则不适用于数据转换或多个数据库合并时经常需要组织的数据。
4、主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。
5、主密钥必须由计算机自动生成。
如果人类干预主键的生成，那么它将与唯一标识一行具有不同的含义。
一旦跨越这个边界，可能就会有修改主密钥的动机，使得该系统用于关联和管理记录行的密钥工具落入那些不了解数据库设计的人的手中。
4.数据库主键选择策略在创建数据库时，我们需要为每个表指定一个主键。
所谓主键就是只能标识一个的一个属性或一组属性表中的行。
有一个主键，但可以有多个候选索引。
由于主键可以唯一标识一行记录，因此可以保证更新和删除数据时不会出现错误。
当然，其他字段可以帮助我们在执行这些操作时消除共享冲突，但这里不再讨论。
除了上述功能外，主键常常与外键形成参照完整性约束，以防止数据不一致。
因此，主键在数据库设计中起着非常重要的作用。
选择数据库主键的常用方法包括：•自动增长字段•手动增长字段•UniqueIdentifier•“COMB（组合）”1类自动增长字段许多数据库设计人员喜欢使用自动增长字段，因为它易于使用。
自动增长字段允许我们将数据添加到数据库中，而不管主键的值是什么。
插入记录后，数据库系统会自动为其分配一个值，以确保永远不会重复。
如果我们使用SQLServer数据库，我们还可以使用@@Identity全局变量来获取记录插入后系统分配的主键值。
虽然自增字段会为我们省去很多繁琐的工作，但使用时也存在潜在的问题，那就是在数据缓冲模式下，很难预先填充键值主键和外键。
。
假设有两个表：Order(OrderID,OrderDate)OrderDetial(OrderID,LineNum,ProductID,Price)Order表中的OrderID是一个自动增长的字段。
现在我们需要输入一个订单，其中包括向Order表中插入一条记录，以及向OrderDetail表中插入一些记录。
由于Order表中的OrderID是一个自动增长的字段，因此在最终记录插入数据库之前我们无法提前知道它的值。
只有更新后我们才能知道数据库赋予它的值。
这将导致以下冲突：首先，为了将正确的值添加到OrderDetail的OrderID字段中，必须更新Order表以获取系统分配给它的OrderID值，然后使用该值来填写OrderDetail。
桌子。
最后更新OderDetail表。
但是，为了保证数据一致性，Order和OrderDetail必须在事务保护下同时更新，这意味着要保证两个表同时更新成功。
显然它们是矛盾的。
另外，当我们需要在多个数据库之间复制数据时（SQLServer的数据分发和订阅机制允许我们在数据库之间复制数据），字段自动填充会导致数据合并时的主键冲突。
想象一下，当一个数据库中的Order表将数据库复制到另一个数据库中的Order表时，OrderID会自动增加吗？ADO.NET允许我们将DataSet中的某个字段设置为自动增长字段，但请记住，这个自动增长字段只是一个占位符。
当数据库更新时，数据库生成的值自动替换ADO。
.NET分配的值。
因此，为避免用户误解，应将ADO.NET中的初始值和自动增长设置为-1。
另外，在ADO.NET中，我们可以为两个表设置DataRelation，这样当两个具有级联关系的表更新时，一个表会更新，另一个表也会更新。
表中对应键的值会也会自动变化，这将大大减少两个具有级联关系的表之间更新时自动增长字段带来的麻烦。
2.手动增长字段既然自动增长字段会带来这样的麻烦，我们也可以考虑使用手动增长字段，这意味着主键的值需要我们维护。
通常，需要创建一个单独的表。
存储当前的主键值。
使用上面的示例，这次我们创建一个名为IntKey的新表，包含两个字段KeyName和KeyValue。
和HashTable一样，给定一个KeyName，你就可以知道当前的KeyValue是什么，然后手动递增键值数据。
在SQLServer中，可以编写这样的存储过程来自动获取键值。
代码如下：CREATEPROCEDURE[GetKey]@KeyNamechar(10),@KeyValueintOUTPUTASUPDATEIntKeySET@KeyValue=KeyValue=KeyValue+1WHEREKeyName=@KeyNameGO这样，通过调用存储过程我们就可以获取到最新的键值，保证有不得重复。
如果OrderID字段设置为手动增长字段，我们的程序可以通过以下步骤实现：首先调用存储过程获取OrderID，然后使用这个OrderID填充Order表和OrderDetail表，最后比较这两个表事务保护表执行更新。
当使用手动增长字段作为主键在数据库之间复制数据时，只要我们为不同的数据库分配不同的主键值段，就可以保证数据合并时不会出现键值冲突。
然而，使用手动开发的字段会增加网络的往返次数。
我们必须通过添加数据库访问来获取当前的主键值，这会在低速网络环境或断开连接时增加网络和数据库的负载。
这种方法会有很大的缺点。
同时，手动维护主密钥还需要考虑并发冲突等各种因素，这会增加系统的复杂性。
3使用UniqueIdentifierSQLServer为我们提供了UniqueIdentifier数据类型并提供了NEWID()构造函数。
使用NEWID()创建它唯一标识符。
UniqueIdentifier在数据库中占用16个字节，重复的概率很小，可以认为是0。
我们经常在注册表中看到类似{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}这样的东西。
它实际上是一个唯一标识符。
Windows使用它来识别COM组件和接口以防止重复。
在.NET中，UniqueIdentifier被称为GUID（GlobalUniqueIdentifier）。
在C#中，可以使用以下命令创建GUID：Guidu=System.Guid.NewGuid();对于上面提到的Order和OrderDetail程序，如果选择UniqueIdentifier作为主键，我们就可以完全避免上面提到的错误。
网络的RoundTrip问题增加。
通过程序直接生成GUID来填充主键，无需考虑是否有重复。
UniqueIdentifier字段也有严重的缺陷：首先，它的长度为16字节，是整数的四倍，占用大量存储空间。
更严重的是，UniqueIdentifier的创建是不规则的，在其上创建索引是一个非常耗时的操作（大多数数据库在主键上都有索引）。
有人做过测试，发现插入相同量的数据时，使用UniqueIdentifier类型的数据作为主键比使用Integer类型的数据慢。
尽量。
4.使用“COMB（组合）”类型。
既然以上三种主键类型选择策略各有各的缺点，那么有没有好的办法来应对呢？答案是肯定的。
通过使用COMB类型（数据库中没有COMB类型，它是由JimmyNilsson在《GUID作为主键的成本》一文中设计的），您可以在三种类型之间找到一个很好的平衡。
COMB数据类型的基本设计思想是：由于UniqueIdentifier数据由于不规则性，索引效率较低，影响系统性能，那么我们是否可以通过关联保留UniqueIdentifier的前10个字节，用后6个字节表示呢？GUID创建时的时间（DateTime），因此我们将时间信息与UniqueIdentifier结合起来，保留UniqueIdentifier的唯一性还可以增加有序性以提高索引效率。
有些人可能担心将UniqueIdentifier减少到10字节会导致数据重复。
其实不用担心。
最后6个字节的计时精度可以达到1/300秒。
两个COMB数据类型相同的可能性。
就是几秒内生成的两个GUID的前10个字节有1/300完全相同，这几乎是不可能的！在SQLServer中使用SQL命令来实现这个想法是：DECLARE@aGuidUNIQUEIDENTIFIERSET@aGuid=CAST(CAST(NEWID()ASBINARY(10))+CAST(GETDATE()ASBINARY(6))ASUNIQUEIDENTIFIER)经过测试时，使用COMB作为主键在检索、插入、更新等方面仍然比使用INT作为主键慢删除等操作，但比Unidentifier类型要快。
以上是引擎中主键和外键的简单介绍SQL数据库。
如有差异请忽略！