RE: Need ideas for SQL join select to replace logical view -- MIDRANGE-L

Joe,

As I consider it, it seems to me that the owner end timestamp really isn't derived from the start of
the next owner timestamp.

Consider the question:
Who owned the car from 2/5/06@4:01 to 2/6/06@11:09?

I believe the derived answer would be Bill. But I think the correct answer is nobody, given the
original data.

However, if the OWNER table was chronologically complete as Chuck suggested, then I agree with you
that owner end timestamp would be derivable.

With a non-complete OWNER table, you've got to get the owner end time from someplace else.

As I see it, there's two options.
1) If the ownership period is separate from anything else, then you need to store start & end.
2) If for instance, a particular transaction indicates start & end, then you can derive both from the
transaction table.

Charles

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Monday, September 17, 2007 9:05 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Need ideas for SQL join select to replace logical view

From: Wilt, Charles

Not sure I agree with this.

There's a difference between storing the same data in two

places, and

storing two separate pieces of data that happen to have the

same value.

Sure, Charles, but these two pieces don't "happen" to have
the same value.
The determining factor is whether one piece can be derived
from another.
And in this case, the start of one event can most certainly
be derived from the end of the previous one.

Actually, given that BETWEEN is inclusive as you pointed out, I'd
considering setting this up so that the end time didn't

match the next

start time. Instead, the start time would be 1 mircosecond greater
than the last end time.

And would still be derived from the previous end time, and
thus would break the normalization rules. This stuff really
isn't subject to interpretation.
You either are or aren't normalized, and putting the same
piece of data (or a derived piece) in another row breaks
normalization, plain and simple.

And note that I'm not saying that "strategic denormalization"
is necessarily bad; as always, it's a business decision.

But in this case, ISAM works on the original data, without
the extra field and without the extra writes. I think that
blaming the database design when SQL needs more data and more
I/O is simply denying the facts, which in this case are
clearly that ISAM is better than SQL for this problem.

Is this horse dead yet?

Joe

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.