Sean Lange (7/29/2014)
Actually normalization (more tables) causes slower performance. That is the nature of the beast. However, in a relational database such as this you want to normalize. When designing your data don't think about how easy it is query and even worse is to change your schema based on performance. This is known as pre-optimization and it will cause you untold amounts of pain in the future.
My experience with reasonably straightforward databases is that nomalisation to 3NF improves performance because it reduces the data size significantly. Of course if you end up needing to join 5o tables the performance will be awful, but tends to happen when you normalise to Date's 6NF and not when you normalise to 3NF.
I would suggest that you have an ingredient table and each ingredient can be of a type (juice, spirit, malt beverage, etc). Then create an IngredientType table to hold the string value.
That looks like the right way to do it to me.
I would avoid the use of sql reserved words like 'name'. Remember that there is nothing wrong with using some descriptive text with object and column names. It will make your life a lot easier in the long run if you use more descriptive names.
One other recommendation is to check your spelling. Category is misspelled. This may not seem like a big deal but common words spelled incorrectly in a database are not fun to work with. Measurement is also misspelled.
I agree with those comments.
Your Category table has 2 columns I don't quite understand (martini and non-alchoholic). Those seem like rows instead of columns.
I am not quite sure what the quantity table is. It looks like a 1:1 with recipes?
I don't understand those bits either.
Tom