in reply to Database Design Issues - OT

While your DBA has an, um--er, *cough*, interesting point, I personally think you've already hit upon the main reasons for doing it correctly:

I don't think you even know if it would save any appreciable amount of time or if there's a problem that needs to be solved. Would it not be wiser to do it right first and then see if there's a problem? His idea is already causing more work, jacking up the expense, and risking data integrity before anyone enters a single record.

If it turns out the second join does cause a problem, there are other approaches that don't risk the data integrity as severely. For example, what if you loaded your category lookup into an array and then printed that value when printing the query results? A tiny performance hit, perhaps...but nowhere as risky as crippling your data integrity from square one.

In my experiences with other databases, I've found that "performance improvements" are applied far earlier than they should be. As an excuse, it frequently gets used to mask sloppy programming or false-laziness. (I've also found that very few people understand normalization and why it's important, but that's another rant.)

Yes, the *are* times to break Codd's Rules--but not many. And the typical reasons for doing so aren't appropriate. IMHO.

Remember the first rule of The Pragmatic Programmer:, "Don't Repeat Yourself."

--f