× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.