About five years ago I started using Generic lookup Tables for applications I was developing. I know, I can hear the sighs and your fists pounding against your desks, but it has proven to cut development time dramatically. If you want a recap, and a strong voice against lookup tables, Jake Christian does a good job summarizing it here:
http://www.projectdmx.com/dbdesign/lookup.aspx
The last project I launched a few days ago had around 20 types of lookup values, ranging from State Names to Active statuses. Using the classic N-Tier model, and restricting data access to Stored Procedures, we would have written 20 tables, 80 Stored Procs (1 Select, 1 Edit, 1 Update and 1 Delete per) if we used a “proper” relational model. Instead the Common Lookup Table has 1 table and 4 SPs. Because the access to the lookup values are more frequent, we cache the values in an ASP.NET Application Object.
My question is what are the alternatives, besides creating a table and 4 SPs per lookup type? I am just starting to look at LINQ as replacement to our DAL (EntLib DAAB), so I would be open to hearing about LINQ alternatives as well.
Thank you in advanced for your suggestions.
Writing tables/stored procs is not hard, many tools exist to make this pretty trivial (even including the foreign key relationships not feasible in the MUCK style tables).
What is hard is dealing with change to these structures.
Whilst in your development phase it is likely you will realise some aspect of the model was incorrect and requires simple (it’s floats not integers) or complex (we need an additional layer between these two tables) alteration. If you have just the one development database this can be painful with multiple developers but is not the end of the world.
Change whilst in production can however be very complex and hard to deal with (sometimes requiring updating all the applications at once). CRUD stored procedures avoid almost all these issues for the simple changes but don’t help at all for the complex ones (in fact they might even hinder it) but fundamentally the structure has changed in some significant way and it is likely that if you were using a MUCK that you would miss this in some way and start putting invalid data in to your DB.
Using Linq to Sql doesn’t help a great deal here, since it just lets you write code that looks similar to sql[1] (stored procedures actually get in the way IMO) but it will let you know at compile time that your db code is no longer valid for some types of significant changed in the database schema (especially with regards to FK relationships). It is not much use for ‘semantic’ changes like altering the primary key to cover greater/fewer columns.
Whilst initially developing you can make the overhead of database changes much less by giving every developer their own database, preferably local. This is highly dependent on the associated costs involved of course.
MUCK tables can have their uses, especially when you want to be able to create/delete new ‘columns’ on the fly with next to no cost and maintain their lifetime values as well (schema updates play merry hell with many lifetime techniques) but such uses are relatively rare.
You can make Mucks slightly more pleasant in some respects (though worse in others) by having one table per type, you then get type validity on insert/lookup (you can add constraints that check that the ‘category’ being inserted is of the correct type if desired). Some of this can be hidden behind stored procedures.
[1] I like this don’t get me wrong, it just doesn’t help your specific issue much