我目前正计划开发音乐流媒体应用程序。我想知道作为服务器上的表中的主键会更好。 ID int或唯一字符串。
方法1：
歌曲表： SongID （int），Title（string），* Artist **（string），Length（int），* Album **（string）
类型表 流派（字符串），姓名（字符串）
SongGenre： *** SongID ****（int），*** Genre ****（字符串）
方法2
歌曲表： SongID （int），Title（字符串），* ArtistID **（int），Length（int），* AlbumID **（int）
类型表 GenreID （int），名称（字符串）
SongGenre： *** SongID ****（int），*** GenreID ****（int）
键：粗体 =主键，*字段** =外键
我目前正在使用方法2进行设计，因为我认为它会加快查找性能并减少使用空间，因为int占用的空间比字符串少得多。
这有什么理由不是个好主意吗？有什么我应该知道的吗？
答案 0 :(得分：17)
您正在做正确的事情 - 身份字段应该是数字而不是基于字符串，这既节省空间又出于性能原因（字符串上的匹配键比整数上的匹配慢）。
答案 1 :(得分：12)
这有什么理由不是一个好主意吗？有什么我应该知道的吗？
是。如果需要在单个数据库之外唯一标识相同的数据，则整数ID非常糟糕。例如，如果必须将相同的数据复制到具有可能预先存在的数据的另一个数据库系统中，或者您具有分布式数据库。最值得注意的是，像7481这样的整数在该数据库之外没有任何意义。如果以后需要增长该数据库，则可能无法通过手术删除您的数据。
要记住的另一件事是整数ID不具备灵活性，因此它们不能轻易用于特殊情况。互联网协议的设计者理解这一点并采取预防措施，将某些数字块分配为＆＃34;特殊＆＃34;以某种方式（广播IP，私有IP，网络IP）。但这只是可能的，因为围绕这些数字的使用存在协议。许多数据库都不能在如此明确的协议中运行。
FWIW，它有点像试图决定是否有一个强烈打字的＆＃34;编程范式优于弱/动态类型＆＃34;编程范式。这取决于你需要做什么。
答案 2 :(得分：7)
从软件的角度来看，GUID在全球范围内更为独特。
引自：Primary Keys: IDs versus GUIDs
使用GUID作为行标识值感觉更自然 - 和 当然比32位整数更真实独特。数据库大师乔 Celko seems to agree。 GUID主键很适合许多人 开发方案，例如复制，或者何时需要 生成数据库外的主键。但它仍然是一个问题 平衡传统的4字节整数ID和。之间的权衡 16字节GUID：
GUID专业人士
- 每个表，每个数据库，每个服务器都是唯一的
- 允许轻松合并来自不同数据库的记录
- 允许跨多个服务器轻松分发数据库
- 您可以在任何地方生成ID，而不必转发到数据库
- 大多数复制方案都需要GUID列
GUID缺点
- 比传统的4字节索引值大4倍;如果这可能会产生严重的性能和存储影响 你不小心
- 在userid =＆＃39; {BAE7DF4-DDF-3RG-5TY3E3RF456AS10}＆＃39;
的地方进行调试很麻烦- 为了获得最佳性能，生成的GUID应该是部分顺序的（例如，SQL 2005上的newsequentialid（））并且能够使用 聚集索引
答案 3 :(得分：3)
我的建议是：使用ID。
你可以用20000首歌曲重命名“流派”而不会破坏任何东西。
这背后的想法是id标识表中的行。无论这一行是什么都与这个问题无关。
答案 4 :(得分：3)
这在很大程度上取决于个人偏好。
我个人的意见和做法是始终使用整数键并始终使用代理而不是自然键（所以不要直接使用社会安全号码或类型名称）。
有些情况下，自动编号字段不合适或无法缩放。在这些情况下，使用GUID是有意义的，GUID可以是数据库中没有本机数据类型的字符串。
答案 5 :(得分：0)
使用int时，MSSQL可以为您生成这些id（请参阅IDENTITY关键字）