Post #190,407
1/16/05 4:31:58 PM
|
Question for you
Do you think it's ever appropriate to not have a schema "properly normalized"? Hint: I think it is. I can give you an example if you like.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #190,421
1/16/05 8:01:04 PM
|
All the damn time
Data warehousing demands it, unless you have an infinite budget for CPUs.
And even then , the overhead of the multi-cpu matrix will peak and kill you.
|
Post #190,423
1/16/05 8:05:00 PM
|
No hints from the peanut gallery
I was asking someone else what he thinks.
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #190,426
1/16/05 8:11:15 PM
|
Give him the benefit
> Why was it spread over several tables?
> Perhaps your issue was poor normalization
> or schema design. Many shops tend to
> create too many tables.
He was leading up to a critique of full normalization
which in turn kill performance. Of course, "poor"
normalization is a "poor" way of stating it, but
it wasn't to the level of George.
|
Post #190,431
1/16/05 8:29:32 PM
|
Fairy nuff
I read his question as, "Why would you have informatoin about one person in multiple tables?" I assumed he's advocating a "theoretically correct" schema that wouldn't work in the real world. I concede the possibility he's describing a badly over-normalized schema, one of which I have seen in production and it blew chunks.
So tablizer, what were you getting at?
===
Purveyor of Doc Hope's [link|http://DocHope.com|fresh-baked dog biscuits and pet treats].
[link|http://DocHope.com|http://DocHope.com]
|
Post #190,457
1/17/05 1:57:15 AM
|
Barry's right; overnormalization is 1 of Bryce's hobbyhorses
|
Post #190,540
1/17/05 11:25:14 PM
|
Huh? What did I over-normalize?
________________
oop.ismad.com
|
Post #190,551
1/18/05 1:57:24 AM
|
It means the opposite of what you seem to think it does. HTH
|
Post #190,689
1/18/05 9:33:12 PM
|
Okay then, what did I UNDER-normalize?
Is this about that time that the info-world forums took a dump, I helped recreate the threads using a FoxPro script, and then we got into a big argument about storing lists of ID's in a cell instead of creating a many-to-many table? It was a one-shot script, not production ebay. So, lighten up.
________________
oop.ismad.com
|
Post #190,762
1/19/05 10:29:32 AM
|
SIGH... "A hobby-horse" means, something you like to...
...*go on and on about*, not something you like to *do*.
That's why "over-normalization" is "a hobby-horse" of yours -- because you *rant* about it all the time.
I was *not* saying that you like to *do* it.
Is comprehension *finally* starting to -- however slowly -- seep in?
Or shall we go over this for a few more rounds?
[link|mailto:MyUserId@MyISP.CountryCode|Christian R. Conrad]
(I live in Finland, and my e-mail in-box is at the Saunalahti company.)
Your lies are of Microsoftian Scale and boring to boot. Your 'depression' may be the closest you ever come to recognizing truth: you have no 'inferiority complex', you are inferior - and something inside you recognizes this. - [link|http://z.iwethey.org/forums/render/content/show?contentid=71575|Ashton Brown]
|
Post #190,859
1/19/05 6:35:22 PM
|
Note: in this case it really is a bad idea
Our team inherited the database from another team. We created a view that joins the tables together into the view that we need, and querying that view has never come close to being a bottleneck, so we've never fixed it.
But we wouldn't have designed it that way in the first place, and if there were signs that this was becoming a bottleneck, then we'd fix it. (The application wouldn't need much fixing.)
Cheers,
Ben
I have come to believe that idealism without discipline is a quick road to disaster, while discipline without idealism is pointless. -- Aaron Ward (my brother)
|
Post #190,536
1/17/05 11:17:29 PM
|
Re: Question for you
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
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
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
|
