Timeline for Guid vs INT - Which is better as a primary key?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 5, 2022 at 6:29 | history | edited | Paul White♦ | CC BY-SA 4.0 |
Incorporated comment
|
| Dec 13, 2020 at 22:44 | comment | added | drizin | @SolomonRutzky if you have both and set the PK as being the INT-IDENTITY instead of being the GUID you lose the 2 major advantages of guid: 1) You'll have to wait for the db to generate the keys (if you add parent and child there's an extra roundtrip); 2) If you're synching distributed databases you'll have to renumber both your identity of the parent table AND the associated FK of child tables. If your PKs are only guids it's much easier, and then INT can be used only for non-critical things like url-identifiers. | |
| Oct 7, 2015 at 19:05 | comment | added | Solomon Rutzky |
I have used this approach myself and it works quite nicely. The GUID is just an alternate key, with a NonClustered index, and is passed in from the application, but only resides in the primary table. All related tables are related via the INT PK. I find it strange that this approach is not much more common given it is the best of both worlds. It seems like most people just prefer to solve problems in very absolutist terms, not realizing that the PK doesn't need to be a GUID in order for the app to still use GUIDs for global uniqueness and/or portability.
|
|
| Apr 3, 2015 at 17:08 | review | First posts | |||
| Apr 3, 2015 at 17:18 | |||||
| Apr 3, 2015 at 17:04 | history | answered | rmirabelle | CC BY-SA 3.0 |