Primary Keys: IDs vs GUIDs (2007 년 3 월 19 일)

3567 단어 primary
FROM: http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html
Long-time readers of this blog know that I have an inordinate fondness for GUIDs . Each globally unique ID is like a beautiful snowflake: every one a unique item waiting to be born.
Perhaps that's why I read with great interest recent accounts of people switching their database tables from traditional integer primary keys ...
ID  Value--  -----1  Apple2  Orange3  Pear4  Mango
.. to GUID keys.
 
ID                                    Value------------------------------------  -----C87FC84A-EE47-47EE-842C-29E969AC5131  Apple2A734AE4-E0EF-4D77-9F84-51A8365AC5A0  Orange70E2E8DE-500E-4630-B3CB-166131D35C21  Pear15ED815C-921C-4011-8667-7158982951EA  Mango
 
I know what you're thinking. Using sixteen bytes instead of four bytes for a primary key? Have you lost your mind? Those additional 12 bytes do come at a cost. But that cost may not be as great as you think:
  • The Cost of GUIDs as Primary Keys (SQL Server 2000)
  • Myths, GUID vs. Autoincrement (MySQL 5)

  • Using a GUID as a row identity value feels more natural-- and certainly more truly unique-- than a 32-bit integer. Database guru Joe Celko seems to agree . GUID primary keys are a natural fit for many development scenarios, such as replication, or when you need to generate primary keys outside the database. But it's still a question of balancing the tradeoffs between traditional 4-byte integer IDs and 16-byte GUIDs:
     
    GUID Pros
  • Unique across every table, every database, every server
  • Allows easy merging of records from different databases
  • Allows easy distribution of databases across multiple servers
  • You can generate IDs anywhere, instead of having to roundtrip to the database
  • Most replication scenarios require GUID columns anyway

  • GUID Cons
  • It is a whopping 4 times larger than the traditional 4-byte index value; this can have serious performance and storage implications if you're not careful
  • Cumbersome to debug (where userid='{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
  • The generated GUIDs should be partially sequential for best performance (eg, newsequentialid() on SQL 2005) and to enable use of clustered indexes

  •  
    I'm not proposing that every database switch to GUID primary keys, but I do think it's important to know the option is out there. If you're still on the fence, what should I choose for my primary key? has excellent advice and a solid analysis of the tradeoffs.

    좋은 웹페이지 즐겨찾기