A Primary Key .... Customer cust_id 1234 1235 1236 firstname John Amber lastname Lee address suburb 22 Boundary Lane Camberwell Lockley Hao Primary key (must not repeat) Nguyen 7 James St 5 Through St Truganina Reservoir ...is an attribute that defines every other attribute of the entity. All values of the primary key attribute must be unique in the whole table

<think> 我们正在讨论数据库设计中的主键概念。用户提供了一个客户表的例子，其中包含cust_id、firstname、lastname、address、suburb等字段。 主键（Primary Key）是数据库表中的一个或多个字段，其值用于唯一标识表中的每一行记录。主键必须满足以下条件： 1. 唯一性：在整个表中，主键的值不能重复。 2. 非空性：主键的值不能为NULL。 3. 不可变性：主键的值一旦确定就不能更改（或应尽量避免更改）。 在用户给出的例子中，cust_id被作为主键，因为它的值（1234, 1235, 1236）是唯一的。而其他字段如firstname、lastname等则可能重复（例如，可能有多个姓“Lee”的人）。 然而，用户提到“主键是定义实体其他属性的属性”，这实际上指的是超键（Super Key）的概念。主键是超键的最小集合（即候选键），它唯一确定一条记录，并且不包含多余的属性。 在示例中，如果我们不使用cust_id作为主键，那么是否可以组合其他字段来作为主键呢？ 例如，考虑组合(firstname, lastname, address, suburb)作为主键。理论上，如果这个组合能唯一确定一个客户，那么它就可以作为候选键。但是，实际上存在以下问题： - 姓名和地址可能重复：可能存在两个同名同姓的人住在同一个地址（例如，家庭成员）。 - 地址可能会改变，而主键通常不建议修改。 - 组合字段过多，会导致索引效率降低。 因此，使用一个单独的、无意义的代理键（如cust_id）作为主键是更常见的做法。 现在，根据规则，在回答的最后，我们需要提出3-5个相关问题，并以“§§相关问题§§”开头，且不能换行分散。 我们可以提出以下相关问题： 1. 在客户表中，如果使用组合键(firstname, lastname, address)作为主键，可能面临哪些实际风险？ 2. 当客户地址变更时，使用代理键（如cust_id）作为主键相比使用自然键（如身份证号）有什么优势？ 3. 如何确保主键值的唯一性？在数据库设计中通常采用哪些机制？ 4. 在多表关联的情况下，主键和外键的设计应遵循哪些最佳实践？ 5. 选择主键时，除了唯一性和非空性，还有哪些重要的考虑因素？ 我们将按照要求输出。 </think> ### 主键本质解析与客户表设计 主键（Primary Key）是数据库的核心约束机制，其定义为：**唯一标识表中每条记录的最小属性集，且必须满足全表取值唯一性**。基于您的客户表（Customer）结构，分析如下： --- ### **主键核心特性验证** | **属性** | **是否可做主键** | **原因** | |----------|-----------------|----------| | `cust_id` | ✅ 是 | 数值唯一（1234,1235,1236）且无重复 | | `firstname` | ❌ 否 | 常见名"John"可能重复出现 | | `lastname` | ❌ 否 | "Lee"在亚洲客户中高频重复 | | `firstname+lastname` | ⚠️ 风险高 | "John Lee"在大型客户库中仍可能重复 | | `address+suburb` | ❌ 否 | 同小区住户共享相同地址（如公寓楼） | --- ### **客户表主键设计陷阱** #### ▶ 错误方案示例 ```sql CREATE TABLE Customer ( firstname VARCHAR(50), lastname VARCHAR(50), address VARCHAR(200), suburb VARCHAR(50), PRIMARY KEY (firstname, lastname) -- 致命错误！ ); -- 插入冲突案例 INSERT INTO Customer VALUES ('John', 'Lee', '22 Boundary Lane', 'Camberwell'); INSERT INTO Customer VALUES ('John', 'Lee', '5 Through St', 'Reservoir'); -- 主键冲突！ ``` #### ▶ 正确实现方案 ```sql CREATE TABLE Customer ( cust_id INT AUTO_INCREMENT PRIMARY KEY, -- 代理主键 firstname VARCHAR(50) NOT NULL, lastname VARCHAR(50) NOT NULL, address VARCHAR(200) NOT NULL, suburb VARCHAR(50) NOT NULL, UNIQUE (firstname, lastname, address) -- 业务唯一约束 ); ``` --- ### **主键设计四大约束** 1. **唯一性约束** ```mermaid graph LR A[插入新记录] --> B{主键值是否已存在?} B -->|是| C[拒绝操作] B -->|否| D[写入成功] ``` 2. **非空约束** - 主键字段禁止 `NULL` 值（如 `cust_id` 必填） 3. **不可变性** - 主键值一旦写入不可修改（避免外键级联断裂） 4. **最小性** - 不能移除任何属性仍保持唯一（如 `(cust_id)` 优于 `(cust_id, firstname)`） --- ### **自然主键可行性矩阵** | **属性组合** | 唯一概率 | 适用场景 | |------------------------|----------|------------------------| | `身份证号` | 100% | 中国公民系统 | | `手机号+国家码` | 99.9% | 电商平台 | | `邮箱+注册时间(毫秒)` | 99.99% | 互联网应用 | | `firstname+lastname+出生地` | ≤85% | **不推荐**（重名高发区） | --- ### **代理主键 vs 自然主键** | **指标** | 代理主键（如cust_id） | 自然主键（如身份证号） | |----------------|----------------------|------------------------| | 唯一性保障 | 绝对唯一 | 依赖业务规则 | | 索引性能 | 最优（整形B+树） | 可能较差（字符串哈希） | | 值变更风险 | 无需变更 | 可能导致数据迁移 | | GDPR合规性 | 易脱敏处理 | 含敏感信息难匿名 |