Sql 混淆主键概念和规范化

让我们以一个

登录

表为例，该表包含以下列：

id

（主键），

用户名

，

密码

，

状态

id

是主键，但我们仍然通过

username

+

password

搜索表来验证用户。这不违反正常化规则吗

另一个例子：假设我们有两个表，

employer

和

job

employer

表的id在

job

表中用作外键，但

job

表本身有自己的

id

job table
---------
id (primary key) || employer_id (foreign key) || etc etc

---

现在，当我们搜索由雇主发布的工作时，我们使用

雇主id

，但此表有其主键？

任何表上的主键都是唯一标识符，默认情况下会编制索引。这并不意味着记录将始终通过该字段本身进行搜索。现在，当您要将父记录链接到子记录时，可以使用主键来建立关系

在尝试获取记录时，您将使用主键作为不同表之间的链接。例如，你有雇主和雇员。搜索可能会像这样：“给我这个雇主的所有雇员”。现在，雇主是这里的主要实体，我们正在为其寻找相关的员工记录。在这里，雇主id将帮助我们获取相关记录。对相同内容的查询可能如下所示：

SELECT [COLUMN NAMES HERE]
FROM EMPLOYER INNER JOIN EMPLOYEE ON
     EMPLOYER.ID = EMPLOYEE.EMPLOYERID

---

我建议你读一些教程，但是，很快。。。主键是唯一且不为null的id，用于标识表中的条目。外键是对另一个表中id的引用。正如你所说，员工和工作表。在大多数情况下，id是由序列生成的，在插入记录之前，您不知道它的值。 您通常通过用户名、名称等执行搜索。。。用户已知的数据。在您的情况下，当您搜索工作时，您可能会执行加入。联接是表之间的关系（类型更多）。在你的情况下，你会做的

select *
from employer emp inner join job jjj on emp.id = jjj.employer _id

---

当您必须更新/删除记录时，ID在代码方面是有用的。在这种情况下，通常您知道关于记录的一切，包括id，然后您将使用id（也因为id通常有索引，所以查询速度更快）。您通常可以在过滤器中使用的列中创建索引，以减少查询的执行时间。

我们需要区分业务（或候选）键和技术（或代理）键。业务密钥是在现实世界中唯一标识此行的数据项。技术关键是方便数据管理，由一些计算机过程生成，如序列或

sys\u guid（）

是的，使用技术密钥意味着存储冗余信息，但在这种情况下，实用性胜过理论。主键不应更改，但在现实生活中可以更改（例如，人们因各种生活事件而更改姓名）。技术密钥没有任何意义，因此请勿更改。业务密钥通常是复合密钥，这通常不便于强制使用外键（有时非常不受欢迎，例如，当业务密钥是敏感数据项（如社会保险号）时）

因此，表通常有一个ID列作为主键（用于外键关系），并有一个唯一的约束来强制执行业务键

在第一个示例中，

username

是一个业务密钥，

id

是一个技术密钥。这就是为什么我们应该有两个数据模型的原因之一。逻辑数据模型有一个名为

user

的实体，其候选键为

username

。物理数据模型有一个名为

user

的表，主键为

id

，唯一键为

username

对于第二个示例，您似乎正在模拟一个职位空缺的情况。雇主和工作之间的关系是一对多的，即雇主可以为许多工作做广告。因此，

Job

表有自己的主键，

id

，外加一个外键

employer\u id

，它引用了

employer

表的主键。这意味着我们可以为特定雇主找到所有工作。但是由于

作业

表有其自己的主键，我们可以识别每个作业，以便我们可以区分哈里森制药公司的看门人作业和拉维的现金携带公司的看门人作业。（这顺便说明了我们需要技术键的原因：假设

雇主id

外键是

varchar2（128）

字符串，用于

作业

表中的每一行。）

在逻辑数据模型中，

employer\u id

通过指向实体

employee

的链接隐含在实体

job

上，但会显示出来（实际上可能，这取决于工具）。在物理模型中，必须将列添加到依赖表中，因为数据库约束（和联接！）实际上需要该列才能工作

---

因此，我们可以看到规范化适用于业务数据的表示和存储，但数据库引擎的实用性意味着我们需要额外的列来管理数据。

什么是

|

？请不要发明你自己的元语言，其他人不会理解它。