Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
Is it easier to implement domain-driven design when using guids as identity fields instead of auto incrementing integers? With guids you don’t have to jump to the database to get the actual value.
Well, GUIDs are easy and look like the best fit. They’re tempting to frontend programmers, since they don’t have to deal with the database.
On the other hand, when looking at the potential drawbacks they have when used without thinking about database issues too much, I would warn against them as much as possible.
The question really is: do you really need to know the ID of the entity before it’s stored in the databsae? REALLY? WHY?
If you do decide to go with GUIDs in the end, and if you’re using SQL Server as your database backend (I don’t know enough about other RDBMS to make an informed suggestion), I would strongly recommend you make absolutely sure that the GUIDs are not being used as the clustering key on the tables. This will kill your performance – no doubt.
If you do use GUIDs as your primary key, make sure to use something else, some other column that wrecks less havoc on your database, as your clustering key instead – a INT IDENTITY would be my first choice.
Check out these articles by Kimberly Tripp on why a GUID is definitely not a good idea as a clustering key in a SQL Server database – she’s the ultimate guru when it comes to indexing and performance issues with indexing and she can makes those points much better than I ever could:
Marc