sql - 代理键 'preference' 解释

标签 sql database-design surrogate-key natural-key

据我所知,自然键的纯粹主义者和代理键的纯粹主义者之间正在发生一场 war 。在喜欢这个this发布(还有更多)人们说“自然键对您不利,请始终使用代理...

但是,我要么是愚蠢的要么是盲目的,但我看不出总是有代理键的理由!

假设您有 3 个表配置如下:Link table

为什么我需要一个代理键?我的意思是没有它是完全合理的。

另外,有人能解释一下为什么主键不应该根据代理键纯粹主义者的说法而改变吗?我的意思是,如果我说 color_id VARCHAR(30) 并且键是 black,我不再需要黑色,因为我将其更改为 charcoal,为什么将 black 键更改为 charcoal 以及所有引用列也是一个坏主意?

编辑:刚刚注意到我什至不需要更改它!只需创建一个新的,更改引用列(就像我对代理键所做的一样),然后让旧的保持平静....

在代理键咒语中,我需要创建额外的条目,例如 id=232name=black。这对我有什么好处?我在 table 上有一把备用 key ,我不再需要了。另外我需要加入才能获得颜色名称,否则我可以留在一张 table 上开心吗?

请向 5 岁的 child 解释一下,请记住,我并不是要说“代理键不好”,而是要理解为什么有人会说“始终使用代理键!”之类的话。

最佳答案

在存在次优自然键的情况下,代理键很有用:不多也不少。 次优的自然键将是 GUID 或 varchar 或其他宽/无序。

但是,使用代理的决定是在概念和逻辑建模过程之后的实现决定,基于对所选 RDBMS 如何工作的了解。

但是,“拥有代理键​​”的最佳做法现在是“始终拥有代理键​​”,并且立即引入。对象关系映射器还经常向所有表添加代理键,无论是否需要,这都无济于事。

对于链接(多对多)表,您不需要一个:SQL: Do you need an auto-incremental primary key for Many-Many tables? .对于具有 2 个 int 列的表,开销是代理列数据的额外 50%(假设为 int 并忽略行元数据)

关于sql - 代理键 'preference' 解释,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16517262/

相关文章:

oracle - 数据库重新设计/模式生成工具

mysql - 关于使用电子邮件地址作为主键的想法

mysql - Web 应用程序用户表主键 : surrogate key vs username vs email vs customer Id

sql - 从 PostgreSQL 将包含换行符的数据导出为 CSV

python - 将 SQL 故障转移合作伙伴与 pyodbc 结合使用

SQL Server 索引/SQL 性能增强

MySQL : One database for all users or multiple databases for each user

python - 将聊天记录存储在关系数据库中

sql - 查找表——自然键或代理键作为主键?

sql - SQL Server 2016 上插入或更新的安全解决方案