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:
(Cryptic Epigram) "Shortcuts make long delays."
(Fragile Integrity): Duplicated data is bad data; all it takes is one typo to break the links. And cleaning up bad data is the most expensive bug fix of all, for it requires human analysis (preferably at hourly rates).
(Ugly American): I presume the site is predominately English. It sounds like they don't plan to deal with the rest of the world--ever. OH? They might be considering presenting their content in Spanish, French, or other languages?
Hm. Guess that means the next one to follow you will have to find lots hard-coded data values in order to make it even possible without a redesign.
(Pendantic Storage Efficiency): How large are your category names? Longer than the storage needed for a single numeric (single or double, take your pick) value?
And so on...I'd keep going, but I am neither as poetic as Cyrano nor as quick-witted as Larry.
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
|
---|