Re: Question for you

Post #190,536

1/17/05 11:17:29 PM

Software design involves gambles. Non-normalizing may help for certain kinds of usage, but at the risk of not being able to handle future requirements that are not favored by the unnormalized stuff. Whether it is worth gambling away future flexibility to get performance for a specific usage pattern today is a business decision similar to financial decision cost analysis. I would suggest looking for ways to improve performance under normalization before giving in to denormalization for speed.

And as somebody pointed out, historical (read-only) data is sometimes easier to sift or use if denormalized. This is because most of such research is done from a customer sales perspective rather than concerned with internal processes about already-completed stuff.

________________
oop.ismad.com

Post #190,547

by static

1/18/05 1:25:03 AM

Also called trade-offs.

... I would suggest looking for ways to improve performance under normalization before giving in to denormalization for speed.

I would agree. IMO, far too many people underestimate maintainability problems with a difficult schema, normalized or not.

And as somebody pointed out, historical (read-only) data is sometimes easier to sift or use if denormalized. This is because most of such research is done from a customer sales perspective rather than concerned with internal processes about already-completed stuff.

This is actually true right now for the application I'm maintaining.

I've found normalizing wins points when it eliminates clearly duplicated and errant data. However, it is possible to hide the normalization in the interface rather than do it right down at the database. Whilst this makes for hairy code, it is doable and is sometimes the solution. But it sacrifices maintainability.

Then, too, I've found that completely normalising the data can sometimes make it harder to use the database. In the simplest case, code to fetch data might change from reading one or two tables to having to dance on 6 or 7. Often not a huge problem, true, until an update is required, too.

Wade.

Is it enough to love
Is it enough to breathe
Somebody rip my heart out
And leave me here to bleed

Is it enough to die
Somebody save my life
I'd rather be Anything but Ordinary
Please

-- "Anything but Ordinary" by Avril Lavigne.

Post #190,696

by tablizer

1/18/05 9:53:21 PM

re: Also called trade-offs

Then, too, I've found that completely normalising the data can sometimes make it harder to use the database. In the simplest case, code to fetch data might change from reading one or two tables to having to dance on 6 or 7. Often not a huge problem, true, until an update is required, too.

I generally only see this if somebody creates a lot of 1-to-1 or 1-to-0:1 relationships. I generally frown on that. When in doubt, make one bigger table instead of multiple smaller (or skinnier) tables.

________________
oop.ismad.com

Welcome to IWETHEY!