Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Hey trying to create a simple database table for a small beer review project, it been awhile since i have created db's so could anyone just tell me if i am totally wrong here?

Especially my use of unique identifiers, as i see it they would always be unique?

Project description: A simple site containing beer data, and information on specific key elements like brewery etc. people should be able to search by name and read about the beer.

Picture of simple database

share|improve this question
you need to specify more about your project to know if your DB design is O.K – jcho360 Oct 8 '13 at 19:08
I'm not sure why you need uniqueidentifier here. Why wouldn't a simple auto-increment number work for you? – FrustratedWithFormsDesigner Oct 8 '13 at 19:10
auto-increment number would also work, but wasnt sure how to do so, in sql some uniqueID's has the (newid()) as default value. – dahund Oct 8 '13 at 19:21
#jcho i added a small project description – dahund Oct 8 '13 at 19:22
I can't work out why you have the separate beerData table - isn't everything in there appropriate to the beer record? And what's beerType?As @jcho360 says, without more detail behind your decisions, it's hard to say if your design is OK. – Thomas Rushton Oct 8 '13 at 19:46

Without knowing more about your data I'm not sure about your table structure, but I will say that GUIDs/uniqueidentifiers are controversial for clustered indexes. Traditional logic says that your clustered index should be unique, small, and sequential. GUIDs are unique, large, and random. (There is a newsequentialID() function that you could use as a default value to get around the random bit, however.)

An article against random GUIDs as PK/clustering keys: Summary: Your data can end up a scrambled mess, and selects of ranges that should be next to each other can be slowed down. Also, it takes up too much space in large tables and indexes.

An article for random GUIDs as PK/clustering keys: Summary: If you have a LOT of inserts, it might be faster to spread them out instead of having them all be "at the end."

Personally, I think that if you have a specific business/logic reason to use GUIDs, then use them. Otherwise, you might want to consider using an autonumber column instead.

share|improve this answer
Clustered indexes over non-sequential UNIQUEIDENTIFIER types (or where such a UUID is the first key in the index) are generally a bad idea due to page splits leading to bad fragmentation and so forth, but your primary key does not have to be a a clustered index. For many tables where PK searches are usually for a single item it is better to use the single clustered index elsewhere (on column(s) that you regularly perform ranged queries on). – David Spillett Oct 8 '13 at 22:57
Thank you so much, you give a good argument for not using uniqueidentifiers. Would you instead recommend using "ID int IDENTITY(1,1)" instead? – dahund Oct 9 '13 at 6:47
I would, yes. It definitely meets the unique, small, sequential criteria. – Katherine Villyard Oct 9 '13 at 12:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.