精华内容
下载资源
问答
  • 数据库函数依赖___关系模式__范式_候选键_主键_码
  • SQL反模式-主键

    2016-09-03 17:34:51
    1 合理使用主键的反模式 如果你设计过数据库,首要就是要明白主键的作用,当然不限于以下的几种理由 a、确保数据行在整张表的唯一性 b、快速定位到一条记录 c、被外键引用来建立表与表之间的关系。 如何设计...

    1 合理使用主键的反模式
    如果你设计过数据库,首要就是要明白主键的作用,当然不限于以下的几种理由
    a、确保数据行在整张表的唯一性
    b、快速定位到一条记录
    c、被外键引用来建立表与表之间的关系。
    如何设计主键呢?很多书或框架将主键做了一个约束
    a、主键的列名叫做id
    b、数据类型是32位或64位整型(我并不认可这种做法,因为可以使用32位uuid或36位id)。
    c、主键的值是自动生成的来确保唯一的。
    Bill Karwin著的《SQL反模式》则认为上面说的是反模式,也就是不合理。如果针对一个初、中级开发工程师,那么我认为Bill Karwin是对的,的确,会对他们产生误导,以为id成为了主键的同义词,而且认为id作为表的伪主键是必要的,所以Karwin建议使用有意义的关键字作为主键,或者使用联合主键。
    不过还好Karwin并没有把话完全说死,合理使用反模式是值得认可的。
    我的最佳实践是使用id作为所有表的主键,这个id类似java的泛型的概念,采购订单号是id,用户-角色关系表用id作为伪主键,尽管它毫无意义;员工编号也使用id。
    为什么这么做的呢
    我首先反问你认为使用bug_id作为主键有意义,那么该表的其他字段是否都应该加上前缀bug_呢?Oracle对表名有长度限制,如果你强制每个字段都加上表名作为前缀,很容易你就超出了限额。
    然后我想说的是,“厚平台、薄应用”的思想,你就知道管理系统支撑起了平台应用核心,管理系统的快速迭代也势必影响了建

    展开全文
  • 文章目录关系的特性数学定义的关系关系的特性关系不可重复候选码/候选键一个关系中可以有多个候选码/候选键主码/主键主属性与非主属性外码/外键总结:什么是关系 关系的特性 列的同质性,每一列的分量来自与同一个...

    关系的特性

    在这里插入图片描述
    列的同质性,每一列的分量来自与同一个值域

    数学定义的关系

    在这里插入图片描述

    关系的特性

    在这里插入图片描述
    每一列属性都满足第一范式,也就是属性不可再分的特性
    在这里插入图片描述
    关系满足列无关性和行无关性,也就是说每条记录,和每列属性,不因为所在的位置不同而让两个关系不同

    关系不可重复

    在这里插入图片描述
    理论上来说,关系是不可以重复的,也就是不应该有所有属性相同的记录或元组.

    候选码/候选键

    在这里插入图片描述
    在关系中,一个属性或属性组,可以用来唯一标识一个元组,若从该属性中去掉任何一个属性,它就不具有这个特性了,这样的属性组就叫做候选码.

    一个关系中可以有多个候选码/候选键

    在这里插入图片描述

    主码/主键

    在这里插入图片描述
    当有多个候选码时,可以选择一个作为主键.
    DBMS使用主键为主要线索管理关系中的多个元组

    主属性与非主属性

    在这里插入图片描述
    包含在任何一个候选码中的属性称为主属性,而其他属性被称为非主属性
    最简单的候选码只包含一个属性
    最极端的,所有属性构成这个关系的候选码,称为全码(All-Key)

    外码/外键

    在这里插入图片描述
    关系R中的一个属性组,它不是本关系的候选码,但它与两一个关系的S的候选码对应,就称这个属性组为R的外码/外键.
    两个关系通常是靠外键关联起来的.

    总结:什么是关系

    如图
    在这里插入图片描述

    展开全文
  • 在基于关系型数据库设计时候,通常要为每张表指定一个主键,所谓主键就是能够唯一标识表中某一行记录的属性或属性组,一个表只能有一个主键,但可以 有多个候选索引。因为主键可以唯一标识某一行记录,所以可以确保...

    在基于关系型数据库设计时候,通常要为每张表指定一个主键,所谓主键就是能够唯一标识表中某一行记录的属性或属性组,一个表只能有一个主键,但可以 有多个候选索引。因为主键可以唯一标识某一行记录,所以可以确保执行数据更新、删除、修改时不出现错误。当然,其它字段可以辅助我们在执行这些操作时消除 共享冲突,不是本文讨论的重点,不再赘述。主键除了上述作用外,常常与外键构成参照完整性约束,防止出现数据不一致。所以数据库在设计时,主键起到了很重 要的作用。常见的数据库主键选取方式有: 自动增长式、手动增长式 、UniqueIdentifier、联合式(复合式)、时间序列+随机数式、“COMB(Combine)”类型。
    一、自动增长式
    很多数据库设计者喜欢使用自动增长型字段,因为它使用简单。自动增长式允许我们在向数据库添加数据时,不考虑主键的取值,记录插入后,数据库系统会 自动为其分配一个值,确保绝对不会出现重复。如果使用SQL Server数据库的话,我们还可以在记录插入后使用@@IDENTITY全局变量获取系统分配的主键值。 
    尽管自动增长式字段会省掉我们很多繁琐的工作,但使用它也存在潜在的问题,那就是在数据缓冲模式下,很难预先填写主键与外键的值。假设有主辅两张表:
    Order(OrderID, OrderDate)  订单表
    OrderDetial(OrderID, LineNum, ProductID, Price)  订单明细表
    Order 表中的OrderID是自动增长型的字段。假设现在需要我们录入一张订单,包括在Order表中插入一条记录以及在OrderDetail表中插入若干条 记录。因为Order表中的OrderID是自动增长型的字段,那么我们在记录正式插入到数据库之前无法事先得知它的取值,只有在更新后才能知道数据库为 它分配的是什么值。这会造成以下矛盾发生: 
    首先,为了能在OrderDetail的OrderID字段中添入正确的值,必须先更新 Order表以获取到系统为其分配的OrderID值,然后再用这个OrderID填充OrderDetail表的OrderID列。最后更新 OderDetail表。但是,为了确保数据的一致性,Order与OrderDetail在更新时必须在事务模式下进行的,即要么两张表同时同时更新成 功、要么全部失败,显然它们是相互矛盾的。 
     其次,当我们需要在多个数据库间进行数据的复制时(SQL Server的数据分发、订阅机制允许我们进行库间的数据复制操作),自动增长式字段可能造成数据合并时的主键冲突及表关联关系的丢失。设想一个数据库中 的Order表向另一个库中的Order表复制数据库时,OrderID到底该不该自动增长呢?如果自动增长,其子表OrderDetial的关联关系会 丢失,如果不增长就会和现有数据主键重复,是不是很矛盾呢? 
    再次,自增量的值都是需要在系统中维护一个全局的数据值,每次插入数据时即对此次值进行增量取值。当在产生唯一标识的并发环境中,每次的增量取值都必须为此全局值加锁解锁以保证增量的唯一性。造成并发瓶颈,降低查询性能。
        还有当数据表足够大或频繁的更改和插入操作导致主键类型值超出范围,这种情况一般很少碰到,但也是我们进行数据表设计时必须考虑的一个问题

    在实际开发中中容易出现主键冲突 主键冲突就是主键出现重复值
    比如 t_user t_admin 都有主键 都是id 自增方式
    Insert into t_user (id)
    Select id from t_admin
    两表中都有主键为 7的时候 插入数据不成功 因为主键冲突
    解决办法
    UPDATE t_admin SET id=-id
    WHERE id IS NOT NULL AND id>0

    Commit;

    二、手动增长型字段
    既然自动增长型字段会带来如此的麻烦,我们不妨考虑使用手动增长型的字段,也就是说主键的值需要自己维护,通常情况下需要建立一张单独的表存储当前 主键键值。为了叙述上的方便仍然利用上面的例子进行阐述,新建一张表叫IntKey,包含两个字段,KeyName以及KeyValue。就像一个 HashTable,给一个KeyName,就可以知道目前的KeyValue是什么,然后手工实现键值数据递增。在SQL Server中可以编写这样一个存储过程,让取键值的过程自动进行。代码如下:
    CREATE PROCEDURE [GetKey] 
    @KeyName char(10), 
    @KeyValue int OUTPUT 
    AS 
    UPDATE IntKey SET @KeyValue = KeyValue = KeyValue + 1 WHERE KeyName = @KeyName 
    GO
    这样,通过调用存储过程,我们可以获得最新键值,确保不会出现重复。若将OrderID字段设置为手动增长式字段,我们的程序可以由以下几步来实 现:首先调用存储过程,获得一个OrderID,然后使用这个OrderID填充Order表与OrderDetail表,最后在事务机制下对两表进行更 新。 
    使用手动增长式字段作为主键在进行数据库间数据复制时,可以确保数据合并过程中不会出现键值冲突,只要为不同的数据表分配不同的主键取值段 就行了。但是,使用手动增长型字段会增加网络的负担,必须通过增加一次数据库访问来获取当前主键键值,这会增加网络和数据库的负载,当处于一个低速或断开 的网络环境中时,这种做法会有很大的弊端。同时,手工维护主键还要考虑并发冲突等种种因素,这更会增加系统的复杂程度。
    三、使用UniqueIdentifier
    SQL Server为我们提供了UniqueIdentifier数据类型,并提供了一个生成函数NEWID( ),使用NEWID( )可以生成一个唯一的UniqueIdentifier。UniqueIdentifier在数据库中占用16个字节,出现重复的概率几乎为0,号称全球 唯一标识。我们经常从注册表或WINDOWS程序出现错误需要调试时看到类似 768427bf-9b37-4776-97ca-000365e160d5或{45F0EB02-0727-4F2E-AAB5- E8AEDEE0CEC5} 的东西实际上就是一个UniqueIdentifier,Windows用它来做COM组件以及接口的标识,防止出现重复。在.NET中 UniqueIdentifier称之为GUID(Global Unique Identifier)。在C#中可以使用如下命令生成一个GUID: 
    Guid u = System.Guid.NewGuid(); 
    对 于上面提到的Order与OrderDetail的程序,如果选用UniqueIdentifier作为主键的话,我们完全可以避免上面提到的增加网络 RoundTrip的问题。通过程序直接生成GUID填充主键,不用考虑是否会出现重复。 但是UniqueIdentifier 字段也存在严重的缺陷:首先,它的长度是16字节,是整数的4倍长,会占用大量存储空间。更为严重的是,UniqueIdentifier的生成毫无规律 可言,也就是说是无序的,要想在上面建立索引(绝大多数数据库在主键上都有索引)是一个非常耗时的操作。有人做过实验,当数据表记录比较大的时,在不同的 数据量级别上插入同样的数据量,使用 UniqueIdentifier型数据做主键要比使用Integer型数据慢,且还没有考虑到表关联的情况,出于效率考虑,尽可能避免使用 UniqueIdentifier型数据库作为主键值,但随着现代计算机计算速度越来越快,在中小型项目中使用UniqueIdentifier式主键也 是一个选项。
    四、使用业务字段联合主键
        
    基于DEPHI和 POWERBUILDER等数据库工具开发C/S系统的数据库设计人员,习惯上用有业务意义的字段组合成复合主键做数据表主键。使用业务主键当然有其与生 俱来的好处,一般情况下数据库系统会在默认条件下建立聚簇索引,而且这个聚簇索引基于主键升序排列,当数据量比较小时,我们感觉不到这种差别,当数据量比 较大时,这种基于主键定义的聚簇索引的优势就显现出来,这就使得数据表在每次存取数据时按照索引准确确认数据插入或更新的磁盘物理位置,减少磁头寻址时 间,从而提高数据库性能,而且能够从业务意义上保证数据的完整性,增加程序的可靠性。但是基于业务字段的联合索引,当业务字段选用比较多时会占用比较多的 磁盘空间,而且索引页会占用更多的内存页面,从而导致查询命中率降低;另外使用业务主键,当涉及到主键数据的修改时,要在编程过程中记录新值和原值的关系 表,在更新时又要进行新值和原值的比对,增加编写程序的复杂度。
    五、时间序列+随机数主键
    采用精确到毫秒甚至钠秒级的时间和一个随机产生的两位数做主键,如200911282311528+两位随机数,不失为解决主键问题的一个有效办 法。这样产生的主键既避免了UniqueIdentifier型字段做主键时的无序,又能有效避免自动增长型主键带来的诸如复制和数据导入的麻烦。但在使 用用户众多的网络实时系统中,在时间和空间上仍然不能保证唯一性的问题。
    六、使用“COMB(Combine)”类型
    既然上面五种主键类型选取策略都存在各自的缺点,那么到底有没有好的办法加以解决呢?答案是肯定的。通过使用COMB类型(数据库中没有COMB类 型,它是Jimmy Nilsson在他的“The Cost of GUIDs as Primary Keys”一文中设计出来的),可以在以上众多的主键策略之间采用中庸之道,找到一个很好的平衡点。
    COMB数据类型的基本设计思路是这样的:既然UniqueIdentifier数据因毫无规律可言造成索引效率低下,影响了系统的性能,那么我们 能不能通过组合的方式,保留UniqueIdentifier的前10个字节,用后6个字节表示GUID生成的时间(DateTime),这样我们将时间 信息与 UniqueIdentifier组合起来,在保留UniqueIdentifier的唯一性的同时增加了有序性,以此来提高索引效率。也许有人会担心 UniqueIdentifier减少到10字节会造成数据出现重复,其实不用担心,后6字节的时间精度可以达到1/300秒,两个COMB类型数据完全 相同的可能性是在这1/300秒内生成的两个GUID前10个字节完全相同,这几乎是不可能的!在SQL Server中用SQL命令将这一思路实现出来便是:
    DECLARE @aGuid UNIQUEIDENTIFIER 
    SET @aGuid = CAST(CAST(NEWID() AS BINARY(10)) 

    • CAST(GETDATE() AS BINARY(6)) AS UNIQUEIDENTIFIER)
      经过测试,使用COMB做主键比使用INT做主键,在检索、插入、更新、删除等操作上仍然显慢,但比Unidentifier类型要快上一些。除了使用存储过程实现COMB数据外,我们也可以使用C#生成COMB数据,这样所有主键生成工作可以在客户端完成。
      C#代码如下: 
      复制代码代码如下:

    //================================================ 
    /<summary> 
    /// 返回 GUID 用于数据库操作,特定的时间代码可以提高检索效率 
    /// </summary> 
    /// <returns>COMB (GUID 与时间混合型) 类型 GUID 数据</returns> 
    public static Guid NewComb() 

    byte[] guidArray = System.Guid.NewGuid().ToByteArray(); 
    DateTime baseDate = new DateTime(1900,1,1); 
    DateTime now = DateTime.Now; 
    // Get the days and milliseconds which will be used to build the byte string 
    TimeSpan days = new TimeSpan(now.Ticks - baseDate.Ticks); 
    TimeSpan msecs = new TimeSpan(now.Ticks - (new DateTime(now.Year, now.Month, now.Day).Ticks));
    // Convert to a byte array 
    // Note that SQL Server is accurate to 1/300th of a millisecond so we divide by 3.333333 
    byte[] daysArray = BitConverter.GetBytes(days.Days); 
    byte[] msecsArray = BitConverter.GetBytes((long)(msecs.TotalMilliseconds/3.333333)); 
    // Reverse the bytes to match SQL Servers ordering 
    Array.Reverse(daysArray); 
    Array.Reverse(msecsArray); 
    // Copy the bytes into the guid 
    Array.Copy(daysArray, daysArray.Length - 2, guidArray, guidArray.Length - 6, 2); 
    Array.Copy(msecsArray, msecsArray.Length - 4, guidArray, guidArray.Length - 4, 4); 
    return new System.Guid(guidArray); 

    //================================================ 
    /
    <summary> 
    /// 从 SQL SERVER 返回的 GUID 中生成时间信息 
    /// </summary> 
    /// <param name="guid">包含时间信息的 COMB </param> 
    /// <returns>时间</returns> 
    public static DateTime GetDateFromComb(System.Guid guid) 

    DateTime baseDate = new DateTime(1900,1,1); 
    byte[] daysArray = new byte[4]; 
    byte[] msecsArray = new byte[4]; 
    byte[] guidArray = guid.ToByteArray(); 
    // Copy the date parts of the guid to the respective byte arrays. 
    Array.Copy(guidArray, guidArray.Length - 6, daysArray, 2, 2); 
    Array.Copy(guidArray, guidArray.Length - 4, msecsArray, 0, 4); 
    // Reverse the arrays to put them into the appropriate order 
    Array.Reverse(daysArray); 
    Array.Reverse(msecsArray); 
    // Convert the bytes to ints 
    int days = BitConverter.ToInt32(daysArray, 0); 
    int msecs = BitConverter.ToInt32(msecsArray, 0); 
    DateTime date = baseDate.AddDays(days); 
    date = date.AddMilliseconds(msecs * 3.333333); 
    return date; 

    综上述六种主键选取策略,我认为使用“COMB(Combine)”类型做主键是比较恰当的主键应用策略,但在实际使用过程中要根据客观实践、因时因事选取适当的主键,切不可生搬硬套、弄巧成拙。

    转载于:https://blog.51cto.com/10975663/2064917

    展开全文
  •  第三范式的定义:如果关系模式R中的所有非主属性对任何候选关键字都不存在传递依赖,则称关系R是属于第三范式的。记作R 3NF。  如:学生关系模式S1(学号,姓名,系号,系名,系地址)  (学号)为关键字,因...
  • 主键(PRIMARY KEY) - 描述 能通过某个字段唯一区分出不同的记录,这个字段被成为主键 - 特性 a.主键必须包含唯一的值 b.主键列不能包含NULL值 c.每个表都应该有一个主键,并且每个表只能有一个主键 - 选取主键的...

    主键(PRIMARY KEY)


    - 描述

    能通过某个字段唯一区分出不同的记录,这个字段被成为主键

    - 特性

    a.主键必须包含唯一的值
    b.主键列不能包含NULL值
    c.每个表都应该有一个主键,并且每个表只能有一个主键

    - 选取主键的基本原则

    不使用任何业务相关的字段作为主键

    身份证号、手机号、邮箱地址均不可用作主键

    作为主键最好是完全与业务无关的字段,通常将这个字段命名为id,常见的id字段类型:

    a.自增整数类型:数据库会在插入数据时自动为每一条记录分配一个自增整数

    b.全局唯一GUID类型:使用一种全局唯一的字符串作为主键,类似8f55d96b-8acc-4636-8cb8-76bf8abc2f57。GUID算法通过网卡MAC地址、时间戳和随机数保证任意计算机在任意时间生成的字符串都是不同的,打不分编程语言都内置了GUID算法,可以预算出主键

    - 联合主键

    关系数据库允许通过多个字段唯一标识记录,即两个或更更多的字段都设置主键,这种主键被成为联合主键。

    联合主键并不常用

    展开全文
  • 参考文章: 廖雪峰SQL教程 关系模型 https://www.liaoxuefeng.com/wiki/1177760294764384/1218728991649984
  • 数据库中的主键与外键的关系,通俗易懂

    万次阅读 多人点赞 2017-12-16 16:13:08
    关系型数据库中的一条记录中有若干个属性,若其中某一个属性组(注意是组)能唯一标识一条记录,该属性组就可以成为一个主键比如学生表(学号,姓名,性别,班级)其中每个学生的学号是唯一的,学号就是一个主键课程表...
  • SQL中主键外键关系

    千次阅读 热门讨论 2013-07-21 20:08:06
    在学过数据库以后对于约束的概念就不是太陌生了,即:约束(Constraint)是Microsoft SQL Server 提供的自动保持... 主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能
  • 将E-R图转换成关系模式

    千次阅读 2019-04-26 20:49:57
    常规实体类型的映射 常规实体类型的特征 强实体,有简单属性,有复合...如果实体类型E有多个候选键,选择其中一个,作为关系模式E的主键,其他的作为备用键 实体类型E的每一个实体实例,对应关系模式E的一个元组 二...
  • ER模型转关系模式

    千次阅读 多人点赞 2015-10-25 12:11:28
    ER图中的主要成分为实体类型和联系类型,转换算法将实体类型和联系类型转换为关系模式。转化为关系模式,主要确定3部分内容,关系模式的名称,属性,码。 转换分为两个步骤:1.实体的转换。2.关系模式的转换; 1....
  • ER图向关系模式转换

    万次阅读 2019-08-16 15:28:20
    实体的转换:在从ER图转换为关系模式时,一个实体就转换一个关系模式,实体的属性就是关系模式的属性,实体的键就是关系的主键。 实体间联系的转换:实体间存在三种联系,即1:1(一对一),1:n(一对多),m:n(多对...
  • 简要地说,主键和唯一索引,或者键和索引之间的最主要区别在于:键是一个逻辑层面的概念,涉及到数据模式的设计。从语法角度看,键被定义为一种约束。比方说,如果想定义外键(或称参考约束),那么相关列就必须先...
  • 联合主键关系数据库实际上还允许通过多个字段唯一标识记录,即两个或更多的字段都设置为主键,这种主键被称为联合主键 ;对于联合主键,允许一列有重复,只要不是所有主键链均重复即可 test id_num id_type ...
  • 模式分解之前,首先对于1NF,2NF,3NF,BCNF做一个简明扼要的介绍。 1NF是指数据库表的每一列都是不可分割的基本数据项,即实体中的某个属性不能有多个值或者不能有重复的属性。 2NF要求属性...
  • 对于关系表,有个很重要的约束,就是任意两条记录不能重复。不能重复不是指两条记录不完全相同,而是指能够通过某个字段唯一区分出不同的记录,这个字段被称为主键。 对主键的要求,最关键的一点是:记录一旦插入...
  • 关系模式范式

    2016-08-11 14:07:23
    数据库的关系模式范式就是数据库设计要满足的规范,满足这些规范的数据库是简洁的,结构清晰的。 第一范式(1NF):所有的列不可再分 第一范式就是指所有的列都是不可再分的基本数据项,即表中的每一列都不能有多个...
  • 解决sqoop导入关系库更新联合主键的问题,把数据从hive中导入关系库,如果关系库表有联合主键的情况,且需要把新导入的数据更新原来的数据。
  • 关系模式全部候选关键字的算法,数据库的表与表之间关系模式等应用
  • 主键约束

    2016-11-11 23:15:05
    主键约束
  • 超键(super key):在关系中能唯一标识元组的属性集称为关系模式的超键/码。 候选键(candidate key):不含有多余属性的超键称为候选键,即其真子集不再是超键。 主键(primary key):用户选作元组标识的一个候选键称为...
  • 数据库关系模式的范式总结

    千次阅读 2019-04-25 21:21:01
    目录 什么是关系模式的范式 第一范式(1NF) 第二范式(2NF) ...关系模式的范式是衡量关系模式好坏的标准。范式的种类与数据依赖有着直接联系,满足不同程度要求的关系称为不同的范式等级。其中,...
  • 数据库复习11——关系模式与范式

    千次阅读 2015-06-30 16:53:34
    数据库复习CH11 数据库模式(Schema)是数据库中全体数据的逻辑结构和特征的描述,关系型数据库的模式又叫关系模式,我所理解的关系模式就是数据库中表结构的定义以及多张表之间的逻辑联系关系模式的设计就是根据一...
  • 数据库关系模式的函数依赖习题讲解

    万次阅读 多人点赞 2020-05-15 16:45:10
    设有关系模式 R(职工名,项目名,工资,部门名,部门经理) 如果规定,每个职工可参加多个项目,各领一份工资;每个项目只属于一个部门管理;每个部门只有一个经理。 1. 试写出关系模式 R 的基本函数依赖和主码。 ...
  • ER图转换成关系模式集的规则

    千次阅读 多人点赞 2018-06-06 17:07:46
    在A表里把B表的主键关系的属性加入到A表中 或B表里把A表的主键关系的属性加入到B表中 举例 男人表 身份证号 姓名 年龄 女人身份证号 登记日期 女人表 身份证号 姓名 年龄 A与B=1:N 在A...
  • 关系模式中的各种码(键/关键字)

    千次阅读 2021-03-15 21:02:18
    码,又称键、关键字,英文是key。唯一标识实体的属性集称为码。 ...全码:一个候选码包含关系模式中的所有属性,则该候选码为全码 举个例子: 关系Student(学号,姓名,年龄,院系,班级)...
  • ER图转换成关系模式集的算法

    万次阅读 多人点赞 2016-07-25 11:52:07
    前言    设计数据库的时候,概念模型采用的是ER图的方法,逻辑... 将每个实体类型转换成一个关系模式,实体的属性即为关系模式的属性,实体标识符即为关系模式主键。   步骤二:联系类型的转换    二...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 80,634
精华内容 32,253
关键字:

关系模式的主键