About a year ago, I blogged about the relative merits of using integers or GUIDs as primary keys in databases. The particular cause for concern was what the URLs would look like:
www.mysite.com/View.aspx?id=104
which looks much nicer than
www.mywebsite.com/View.aspx?id=015B34D5-A301-4543-AE1A-16708B19F602
With the advent of ASP.NET MVC, the choice becomes something like:
or
www.mywebsite.com/product/015B34D5-A301-4543-AE1A-16708B19F602
It was because of the consideration of what the URL would look like that I chose to stick with integers for the database I was using at the time.
But the more I have thought about this problem, the more I have come to the conclusion that the database row identifier should never appear in the URL anyway. After all, if you are displaying products, they will also have a unique product code. If you are displaying user details, they will have a user name. If you are displaying categories, they will have a unique name. Even with a blog or CMS system, the trend now is to have a "slug" to give a unique string for each post to use in the "permalink", often combined with the year and month to help avoid naming conflicts. So for example:
www.mysite.com/product/X1494-M
www.mysite.com/category/programming
www.mysite.com/blog/2008/5/welcome-to-my-new-site
If you allow these "slug" fields to be editable by the user, you can use genuinely meaningful URLs, without ever needing to reveal the database key to the user.
So I'm leaning towards using GUIDs again. The only case where I think I would need them to appear in a URL is in admin specific links such as editing or deleting a blog entry, where it would be safer to use them just in case the slug was not unique. They may also be useful to form really permanent permalinks for the cases where the slug itself may be changed in the future.
No comments:
Post a Comment