假设有一个表
User
具有以下属性User: user_id(Primary Key), name, password, phone, username, email, created_on
还有另一张桌子
Customer
Customer: customer_id, dob, gender, user_id (Foreign key to User table)
据此,一位客户或
customer_id
将仅与一位 user_id
相关联。因此customer_id
和user_id
都可以唯一地确定Customer
表中的每条记录。我应该将哪一个视为主键,省略另一个的原因是什么?唯一性:
customer_id
和user_id
在各自的表中都是唯一的。由于user_id
是User
表中的外键,它将唯一标识一个用户,假设每个用户对应一个客户,它也可以唯一标识一个客户。
含义:
customer_id
可能是代理键,这意味着它除了用作数据库中的标识符之外没有任何意义。 user_id
,另一方面,不仅可以识别客户,还可以将该客户与用户配置文件联系起来。
未来变化:如果业务规则发生变化,使得用户将来可以链接到多个客户(例如,如果用户可以拥有多个角色或帐户类型),
user_id
将不再唯一标识一个客户。在这种情况下,customer_id
将是一个更安全的选择,因为它独立于其他实体。
=>
customer_id
应用作 Customer
的主键它可以避免业务规则演变时出现的潜在问题,并且它保持了明确的关注点分离,其中
User
表处理与身份验证相关的属性,而 Customer
表处理客户特定的详细信息。
为了确保
Customer
表标准化为第三范式 (3NF),您应该检查:
1NF(第一范式):
name
不应包含多个名称。customer_id
实现的。2NF(第二范式):
dob
、gender
)必须依赖于整个主键,而不仅仅是其一部分。由于 customer_id
是唯一主键,并且 Customer
中的所有其他属性都依赖于它,所以自然满足这个条件。3NF(第三范式):
Customer
表中的所有属性(dob
、gender
、user_id
)应仅依赖于 customer_id
,而不是相互依赖。Customer
表中的属性不是派生的或相互依赖的,而是仅依赖于主键。通过确保这些条件,您的表结构将是健壮、高效和可扩展的,为扩展数据库模式提供清晰的途径,而不会引入冗余或异常。