SQL Server规范化策略:varchar vs int Identity

我只是想知道这里的最佳解决方案是什么.

假设我有一个规范化的数据库.整个系统的主键是varchar.我想知道的是我应该将这个varchar与一个int相关联以进行规范化还是留下它？离开作为varchar更简单,但它可能更优

比如我可以

People
======================
name      varchar(10)   
DoB       DateTime    
Height    int  

Phone_Number
======================
name      varchar(10)   
number    varchar(15)

或者我可以

People
======================
id        int Identity   
name      varchar(10)   
DoB       DateTime  
Height    int  

Phone_Number
======================
id        int   
number    varchar(15)  

当然,添加其他几个一对多关系.

你们都觉得怎么样？哪个更好？为什么？

我相信大多数开发了大量现实世界数据库应用程序的人都会告诉你,代理键是唯一现实的解决方案.
我知道学术界不同意,但这是理论纯度和实用性之间的差异.

任何合理大小的查询必须在使用非代理键的表之间进行连接,其中某些表具有复合主键很快变得不可维护.

你真的可以使用名字作为主键吗？是不是有几个人同名的高风险？

如果你真的很幸运,你的名字属性可以用作主键,那么 - 无论如何 - 使用它.但是,通常情况下,您必须制作一些内容,例如customer_id等.

最后:"NAME"是至少一个DBMS中的保留字,因此请考虑使用其他内容,例如fullname.

使用任何类型的非合成数据(即来自用户的任何东西,而不是由应用程序生成的)作为PK是有问题的; 您必须担心文化/本地化差异,区分大小写(以及其他问题取决于数据库归类),如果/当用户输入的数据发生变化时,可能会导致数据问题等.

使用非用户生成的数据(顺序GUID(如果您的数据库不支持它们,或者您不关心页面拆分,则为非顺序数据)或标识整数(如果您不需要GUID))更容易更安全.

关于重复数据:我没有看到使用非合成密钥如何保护您.你仍然遇到用户输入"Bob Smith"而不是"Bob K. Smith"或"Smith,Bob"或"bob smith"等问题.无论你的密钥是否是合成的,重复管理都是必要的(并且几乎完全相同)或非合成密钥和非合成密钥具有合成密钥巧妙避免的许多其他潜在问题.

许多项目不需要担心(例如,严格限制的校对选择会避免其中许多项目),但总的来说我更喜欢合成密钥.这并不是说你无法用有机键成功,显然你可以,但对于很多项目来说,它们不是更好的选择.