Jim,
My reponses in line ....

>There is no such thing as "too much normalization" either a design is normalized or it is not.

Well - play with semantics if you like - read my other post to Doug dodge - it points out that a "fully normalized" database is essentially a concept hat few people EVER actually work with.


> Normalization is not a "holy grail" as you have said, however it is an invaluable tool towards eliminating potential design problems in the database early in the development process.

I agree with the valuable tool part but disagree that it is not a "holy grail" to many "over-educated under-common-sensed" (as my late father used to put it) designers who never had to sit down and actually use the applications and databases they create. I have been on projects - big projects - where the DB was normailzed into unusability. I was wondering when they were going to come up with the 'alphabet" and "digit" tables and create a whole database of foreign keys!!!


>Also, your "acedemia" reference is tiersome to me.

and "theory over practicality" is not only tiresome - but loathsome to me :-) To borrow from the old saying - those who can do - those who can't write books on relational theory :-)

>Because denormalization becomes an excuse for never normalizing the design in the first place.
I just call that "laziness" - not an indictment against proper denormalization. I do bel;ieve that one should start with a reasonable normalized database, though I suspect you will disagree with that since you believe normalization is a 1/0 status.


>"If you know what the fully normalized design is, and you know exactly which normal form you are about to violate, and you know why that normal form exists, and you know the exact benefits you will abtain from denormalizing, you know what the consequence of violating that normal form are, then by all means denormalize.

I've never believed, said, or advocated anything different.

Jim - I doubt - on a practical level - we would disagree on much. I suspect our differences are related to perspective. I am a STRONG user advocate and will usually fight on the side that says ANYTHING that makes a program faster or easier for a user to use should almost always take precedence over adherance to theoretical rules and "accepted practices" Of course, you have to be smart and experienced enough to know and avoid the potential pitfalls - and I do.

I am also a pragmatist that believes that it is just as easy to overdesign as it is to underdesign. One must have a clear understanding of the term "diminishing returns" to be a good designer IMHO.

The important thing is that, in the end, the application. WORKS. And by works I mean it does what it is supposed to do in a stable, consistent, predicatble, secure, understandable, and effecient manner.The user could care less whether you use VFP or VB or C++ or OOP or prgs or SEEK or LOCATE or normalized data or any of the list of hundreds of other things that get beat to death on this Forum every day UNLESS it impacts them in some way they can discern. It either works or it don't. Now - issues such as maintainability, RAD, etc. are also of importance and are affected by the issues we discuss, but never confuse the means to an end with the end itself.

Happy Y2K!
Ken