首页 文章

数据库设计Primay Key,ID vs String

提问于
浏览
17

我目前正计划开发音乐流媒体应用程序 . 我想知道作为服务器上的表中的主键会更好 . ID int或唯一字符串 .

方法1:

歌曲表: SongID (int),Title(string),* Artist *(string),Length(int), Album **(string)

类型表 Genre (字符串),名称(字符串)

SongGenre:*** SongID ***(int),类型(字符串)

方法2

歌曲表: SongID (int), Headers (字符串),* ArtistID *(int),长度(int), AlbumID **(int)

类型表 GenreID (int),名称(字符串)

SongGenre:*** SongID *(int), GenreID ****(int)

键: Bold =主键,字段* =外键

我目前正在使用方法2进行设计,因为我相信它会加快查找性能并减少使用空间,因为int占用的空间比字符串少得多 .

有什么理由这不是个好主意吗?有什么我应该知道的吗?

6 回答

  • 17

    你正在做正确的事情 - 身份字段应该是数字而不是基于字符串,既节省空间又出于性能原因(字符串上的匹配键比整数上的匹配慢) .

  • 3

    这有什么理由不是个好主意吗?有什么我应该知道的吗?

    是 . 如果需要在单个数据库之外唯一标识相同的数据,则整数ID非常糟糕 . 例如,如果必须将相同的数据复制到具有可能预先存在的数据的另一个数据库系统中,或者您具有分布式数据库 . 最值得注意的是,像 7481 这样的整数在该数据库之外没有任何意义 . 如果以后需要增长该数据库,则可能无法通过手术删除您的数据 .

    另外要记住的是,整数ID不容易用于特殊情况 . 互联网协议的设计者理解这一点并采取预防措施,将某些数字块分配为某种方式(广播IP,私有IP,网络IP) . 但这只是可能的,因为有一个围绕这些数字使用的协议 . 许多数据库不能在如此明确定义的协议中运行 .

    FWIW,有点像试图决定“强类型”编程范式是否优于“弱/动态类型”编程范例 . 这取决于你需要做什么 .

  • 3

    从软件的角度来看,GUID在全球范围内更为独特 .

    行情来自:Primary Keys: IDs versus GUIDs

    使用GUID作为行标识值比32位整数感觉更自然 - 当然更真实唯一 . 数据库大师Joe Celko似乎同意 . GUID主键很适合许多开发方案,例如复制,或者需要在数据库外部生成主键时 . 但它仍然是在 balancer 传统的4字节整数ID和16字节GUID之间的权衡的问题:GUID优点每个表,每个数据库,每个服务器的唯一性允许轻松合并来自不同数据库的记录允许跨多个服务器轻松分发数据库您可以在任何地方生成ID,而不必转发到数据库大多数复制方案都需要GUID列GUID缺点它比传统的4字节索引值大4倍;如果你不小心,这可能会产生严重的性能和存储影响 . 如果调试userid =',那么生成的GUID应该是部分顺序的以获得最佳性能(例如,SQL 2005上的newsequentialid() )并允许使用聚簇索引

  • 9

    这在很大程度上取决于个人偏好 .

    我的个人观点和做法是始终使用整数键并始终使用代理而不是自然键(因此不要直接使用社会安全号或类型名称之类的东西) .

    有些情况下,自动编号字段不合适或不能缩放 . 在这些情况下,使用GUID是有意义的,GUID可以是数据库中没有本机数据类型的字符串 .

  • 0

    我的建议是:使用id .

    你可以用20000首歌曲重命名“流派”而不会破坏任何东西 .

    这背后的想法是id标识表中的行 . 无论行是什么,这个问题都无关紧要 .

  • 5

    使用int时,MSSQL可以为您生成这些id(请参阅IDENTITY关键字)

相关问题