在sqlserver2000中如何设置主键和外键?

1)主键CREATETABLEWL_Table_04(IDintPRIMARYKEY,Namechar(8),Sexchar(2)NOTNULL)2)外键CREATETABLEWL_Table_05(IDintREFERENCESWL_Table_04(ID),CurseIDcharger(20),Gradeint,CONSTRAINTID_CoursePRIMARYKEY(ID,CourseID))满足以上两项创建表时。

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

1、什么是主键和外键：在关系数据库中，一条记录有多个引用；如果某个属性组（注意是组）可以唯一标识一条记录。
参考组可以成为主键。
例：学生表（学号、姓名、性别、班级）每个学生的学号是唯一的学号是主键用户表（用户名、密码、登录级别）用户名是计算机记录表的主键（卡号、学号）。
,姓名），序列号）不是计算机日志表中的单个属性。
唯一标识一条记录；学号和姓名的组合可以唯一标识一条记录；因此，学号和姓名的参考组是计算机记录表中的序号，而不是班级表的主键。
与学生表中学号、学号对应的主键相同。
是学生表的主键；那么班级表中的学号就说是学生表的外键主键和外键的定义主要是为了维护关系数据库的完整性。
主键是标识记录的唯一标识符，例如记录上的ID号；姓名和年龄包括因为身份证号码是其他人唯一可以识别您身份的信息，ID号是主键。
外键用于与另一个表关联。
它是决定另一个表的记录的字段，用于维护数据的一致性。
例如，如果A表中的某个字段是B表的主键；它可以是表A的外键。
2、主键；外键和索引的区别在于主键；外键和索引有什么区别？定义：记录不能重复。
一个表的外键是另一个表的主键。
但可以有空值：用于保证数据完整性并加快与其他表的联接次数：一张表只能有一个主键。
外键表上的唯一索引聚集索引和非聚集索引有什么区别？聚合索引必须是唯一索引。
但唯一索引不是簇索引。
海量索引直接将数据存储在索引页上；而非聚集索引则将索引存储在索引页上；这些标签指向专门数据页中的数据。
3.数据库中的主键外键的设计原则主键和外键是将多个表绑定在一起形成一个高效的关系数据库的粘合剂。
主键和外键的设计对物理数据库的性能和可用性具有决定性的影响。
数据库规划必须从理论逻辑设计转化为实际物理设计。
主键和外键的结构是此设计过程的核心。
一旦设计的数据库部署到生产环境中；这些键将很难修改；因此，在开发阶段设计主键和外键是非常必要和有价值的。
主键：关系数据库依赖于主键——它们是数据库物理排列的基石。
主键在物理层面只有两个用途：1.唯一标识一个类。
2.作为可以被外键有效引用的对象。
基于以上两种用途，我在物理层面设计主键时遵循以下一些原则：1、主键不应该对用户来说毫无意义。
用户在表示许多关系的连接表中看到和使用的数据较少如果他抱怨，这证明它的钥匙设计得很好。
2、主键应该是单列，以提高连接和过滤操作的效率。
注意：使用组合键的人通常会因为这两个原因发现自己错了。
然而，其一是主键实际上应该具有某种含义。
定义主键仅有助于数据库的虚拟删除。
其次，我反对使用这种方法在表达多键关系的连接表中使用两个外键作为主键：复合主键通常会导致错误的外键。
那是，表连接后，另一个从表同上。
尽管第二种方法构成了该表主键的一部分。
该表可以成为其他从表的主表，并且其主键可以是其他从表主键的一部分。
稍后从属服务器将出现在表中，并且其主键将包含其他列。
3.切勿更新主键。
貌敏，因为主键除了唯一标识一行之外没有其他用途。
没有理由更新它。
如果需要更新主键。
对于用户它违反了主键应该无意义的原则。
注意：此原则不适用于数据迁移或多个数据库集成时需要频繁聚合的数据。
4、主键是时间戳；创建时间栏；它不应包含动态变化的数据，例如修改时间列等。
5.主密钥应由计算机自动生成。
如果人为干扰主键的创建。
它除了唯一标识一个类之外还有其他含义。
一旦跨过这个界限，可能有修改主键的动机；因此，该系统用来链接和排序记录行的密钥将落入不懂数据库设计的人手中。
4、数据库主键选择策略创建数据库时；我们需要为每个表定义一个主键。
主键是一个或一组属性，仅标识表中的一行。
有一个主键；然而，可能存在多个候选索引。
主键唯一标识记录行，从而保证更新和删除数据时不会出现错误。
当然，其他领域在执行这些职能时也存在冲突它们可以帮助删除它们，但我们不会在这里讨论它们。
除了以上功能外，主键通常会通过外键强制执行参照完整性约束，以防止数据不一致。
所以，主键在数据库设计中起着非常重要的作用。
常见的数据库键选择方法包括：•自动增长字段•手动增长字段•UniqueIdentifier•“COMB（组合）”类型1自动增长字段许多数据库设计者更喜欢使用自动增长字段，因为它易于使用。
自动增长字段允许将数据插入数据库，以确保插入记录后数据库系统不会重复。
如果使用SQLServer数据库插入记录后，可以使用@@Identity全局变量获取系统分配的主键值。
自增字段可以为我们节省很多繁琐的工作，但是使用它也存在潜在的问题。
即处于数据缓冲模式；预填充主键和外键的值很困难。
。
Order(OrderID,OrderDate)OrderDetial(OrderID,LineNum,ProductID,Price)Orders表中的OrderID是一个自动增长的字段。
现在我们在订单表上您需要输入一个订单，包括插入一条记录和向OrderDetail表中插入多条记录。
因为Orders表中的OrderID是一个自动增长的字段；只有当记录正式插入数据库后，我们才能知道分配给它的数据库值。
这会产生以下参数：首先，将OrderID字段中的正确值插入到OrderDetail中；必须更新Orders表才能获取系统分配的OrderID值。
然后使用该OrderID填充OrderDetail表。
。
最后，更新OderDetail表。
然而，为了保证数据的一致性，订单和订单明细必须在事务保护下同时更新，这意味着确保两个同时更新成功。
似乎恰恰相反。
此外，当我们需要在多个数据库之间复制数据时（SQLServer的数据分发和订阅机制允许数据在数据库之间复制）；自动增长的字段可能会在数据集成过程中导致关键冲突。
想象一下，当一个数据库中的Orders表将数据库复制到另一数据库中的Orders表时，OrderID应该自动递增。
ADO.NET为我们提供了数据集中的一些字段允许您将其设置为自动增长的字段；但是当这个自动增长的字段更新数据库时。
请记住，数据库生成的值将自动替换ADO。
.NET定义的值。
所以，防止用户误解；在ADO.NET中，建议将自动递增率的初始值设置为-1。
此外，在ADO.NET中，我们可以为两个表建立DataRelation；这样当两个具有级联关系的表更新时；当一张表更新时，下一张表中对应键的值也会自动改变。
这将减少在两个表之间更新时由自动进度字段以及两个表之间的关系引起的问题。
2、手动生长字段导致自动生长字段出现这样的问题，我们也可以考虑使用手动生长字段；这意味着主键的值通常需要在单独的表中创建。
存储当前主键值。
使用上面的示例，这次有两个字段；使用KeyName和KeyValue创建一个名为IntKey的新表。
就像给定KeyName的哈希表一样；您可以知道当前的KeyValue是什么，并手动递增键值数据。
在SQLServer中，你的关键价值你可以写一个这样的存储过程来自动获取它。
代码如下：CREATEPROCEDURE[GetKey]@KeyNamechar(10),@KeyValueintOUTPUTASUPDATEIntKeySET@KeyValue=KeyValue=KeyValue+1WHEREKeyName=@KeyNameGO这样，通过调用最新的存储密钥过程；为了确保我们有空，它不会被重复。
如果OrderID字段设置为自进字段。
我们的程序可以按以下步骤实现：首先调用存储过程获取OrderID；然后使用这个OrderID来填充Orders表和OrderDetail表；然后比较两者。
更新事务保护下的表。
使用增长字段作为主键在数据库之间复制数据时；只要在数据集成过程中将不同的主键值段分配给不同的数据库，就可以保证不会出现键值冲突。
然而，通过在网络和数据库上增加低速或断网环境下的数据库访问，我们将增加网络的RoundTrip。
这种方法有很大的缺点。
同时，由于组合冲突等多种原因，手动维护主键会增加系统的复杂性。
这是需要考虑的。
3使用UniqueIdentifierSQLServer为我们提供了UniqueIdentifier数据类型，并使用NEWID()生成唯一的UniqueIdentifier，使用NEWID()生成生成。
UniqueIdentifier在数据库中占用16字节的空间，可以假设为0，因为重复的概率很小。
注册表中类似{45F0EB02-0727-4F2E-AAB5-E8AEDEE0CEC5}的内容实际上被Windows用作唯一标识符。
在.NET中，UniqueIdentifier被称为GUID（GlobalUniqueIdentifier）。
在C#中，您可以使用以下命令生成GUID：Guidu=System.Guid.NewGuid();对于上述Order和OrderDetail程序；如果选择UniqueIdentifier作为主键。
我们完全可以避免上述情况。
增加了网络往返问题。
填充主键的GUID是通过程序直接生成的，不考虑是否存在重复。
UniqueIdentifier字段也有严重的缺陷：首先，它的长度是16字节。
它比整数长4倍，占用大量存储空间。
更严重的是，UniqueIdentifier的生成是不正确的，在其上创建索引是一个非常耗时的操作（大多数数据库都有主键索引）。
因为有人做过实验，发现在输入相同量的数据时，使用UniqueIdentifier类型的数据作为主键比使用Integer类型的数据慢。
为了有效，避免将数据库类型UniqueIdentifier作为主键值。
尽可能使用“COMB”类型上面的三种主要键类型选择策略都有各自的缺点，有没有好的方法来解决它们？答案是肯定的。
通过使用COMB类型（数据库中没有COMB类型，它是由JimmyNilsson在他的文章“GUID作为主键的成本”中设计的）；你可以在三者之间找到一个平衡点。
COMB数据类型的基本设计思想如下：由于UniqueIdentifier数据由于其不规则性，索引度较低，影响系统的性能；可以使用串联来保留UniqueIdentifier的前10个字节。
最后6个字节表示GUID生成的时间（DateTime）；因此，我们将时间信息与UniqueIdentifier结合起来，保留UniqueI标识符的唯一性，也增加了提高索引能力的顺序。
事实上，将UniqueIdentifier减少到10个字节会重复数据。
最后6个字节的时间精度可以达到1/300秒，并且两个COMB类型的数据很可能是相同的。
在1/300秒内生成的两个GUID的前10个字节几乎不可能完全相同。
在SQLServer中使用SQL命令来实现这个概念：测试后声明@aGuidUNIQUEIDENTIFIERSET@aGuid=CAST(CAST(NEWID()ASBINARY(10))+CAST(GETDATE()ASBINARY(6))ASUNIQUEIDENTIFIER)使用COMB作为主键允许恢复；安装更新；它仍然比使用INT作为主键进行删除等操作慢，但比Unidentifier类型快。
以上是对SQL数据库中主键和外键的简单介绍，如有不一致之处，敬请谅解。