To me, the rules for normalizing databases are just a roundabout way of saying - build them as objects.
You put rationally grouped data together in tables in such a way that you avoid nulls and do not duplicate data anywhere. First Normal Eliminate duplicate columns Group related data and identify each row with a primary key Second Normal Remove subsets of data that are duplicated and put them in a separate table (create a related ojbect) Create relationships through the use of foreign keys Third Normal Remove columns that are not dependent on the primary key. (This one can be a little iffy sometimes but basically you could restate it as - make sure your object only has related items). If you follow these rules don't you end up with objects? In the broad sense of the word - employee objects, address objects etc. To me you should architect the system and then build the database first. From the business point of view the database is the, by far, most important element. It is where the business "treasure" is - where the value is. The middleware or the GUI can always be changed (and probably will be) but the data will only migrate and if it is in SQL Server or Oracle probably not even that. Also, if the database is well written then the middleware becomes easy to write, your SQL statements tend to be very simple etc. I write like you Aaron - database first. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en -~----------~----~----~----~------~----~------~--~---
