but you dont know how many records can be there in child table . Also if the
status changes for child record you will have to take care of updating teh
parent one also .
-bp
- Original Message -
To: Multiple recipients of list ORACLE-L [EMAIL PROTECTED]
Sent: Wednesday, August 14, 2002
This is to thank all those who replied to my post -
Thomas, Dennis, Jack, Melissa, Manavendra, Jerome,
Steven , Stephen and Michael (sorry if I missed
someone). I have been able to create the aggregate
which IMO will speed up the reports so hopefully the
developers will go along.
thank you all
Gene,
You ask what's wrong with this? The main challenge I see is: how are you
going to maintain this field? If a status gets updated in the child table,
are you supposed to update the parent table? And to do that, you will need
to requery the child table to get all the status's of all
Sounds like a bit of denormalization. Which during development you may have
to do for performance reasons. Checkout www.dmreview.com for some articles
on this. Or Ralph Kimball's site.
I believe one of the design rules state that you would want to avoid
creating those STATUS_A_CNT, etc.
With individual columns you save on the CPU cycles/time involved to parse
the string and extract each character.
Additionally, if you ever need to update this string, it would be tedious.
IMO, its always better to have atomic data since one can then leverage the
features of the DBMS.
With Warm
Title: RE: what is wrong with this idea ...
Gene,
You would be denormalizing to hopefully improve performance. The only way to tell is to test and test some more. Personally I don't see how putting the info in the parent table with either method will improve things. I bet updates
Tom,
The child table is not going to be updated ad-hoc.
As I said this is a data warehouse and there is no
ad-hoc updates. Only one load during the day and
during
this load that field is going to be populated.
The thing I don't like about the procedure is that it
will be doing a query against
-- Gurelei [EMAIL PROTECTED]
Hi. We have a table in our data warehouse which keeps
info about calls made. This table has a child table
with some detailed information about parts of the
call. There may be any number of parts within a call
(1 to many) and every part has a status.
MY
Gene - What is the motivation here? Are you trying to save space in a fact
table with many, many rows? I agree that in data warehousing we sometimes
violate the normal rules we adhere to in OLTP databases, and I think some of
your responses have been assuming OLTP rules. For example, someone
Gene,
you asked what was wrong and I think everyone gave you their opinion.
you know by now that what you are told today will change next month. once
you begin down this path, you will never stop. you know that as soon as you
set this up, and they have written a ton of reports, that a new
Gene,
One of the basic rules of third normal form is to not
store multiple (non-atomic) values or logic inside a
column like this. The reason is that you end up
storing the same values more than once, wasting space,
and you have to substr the value to get your logic out
of it, which could
Dennis,
Yes, at this moment I'm debating whether to go with
one combined string or several separate fields.
I'm not thrilled by any of the options, but the former
really doesn't look good to me. What I'm trying to
avoid is every transaction having to run a query
against a large (tens of millions
I'd prefer to build a normalized ODS structure and then build
any denormalized structures on top of it. Thus, I'd keep the
Parent to Child relationship and put each status in it's own
row, with a temporal time stamp. If you need some denormalized
view of that (because of performance) then I'd
Title: RE: what is wrong with this idea ...
If you are using 8i+ consider using materl. views. They are wonderful and make maintenance of denormalized objects much less of a chore. I am oh so happy with them. There are some limitations but still.
-Original Message-
From: Gurelei
14 matches
Mail list logo
