× 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.



From: CRPence

IMO the problem is the database design. Historical ownership can not
be correctly represented with only a transaction time.

And yet, with a simple ISAM access, we can generate the required report with
the existing database. It seems to me that it is NOT the database design
that is at fault, but simply the wrong choice of tool.


Such historical
ownership would be a duration. The ownership table also fails to denote
that the *STORE is the owner between transactions which would complete
known ownership history.
I would define the OWNER table to have a column for both a FROM_TMSP
and UNTIL_TMSP to designate the duration that the item is owned; the end
of the duration is CURRENT TIMESTAMP when not defined.

That's all well and good, but it also requires more fields as well as extra
writes to the database. It's hard to consider a database design better than
another if it increases both storage requirements and workload.

I'm not saying your solution doesn't work, just that it is not without its
own problems. And sometimes changing the database just isn't an option.
That's when ISAM really shines - when your data isn't perfect.



SELECT i.*, o.owner
FROM INVENTORY I
LEFT OUTER JOIN OWNER O
WHERE i.tmsp BETWEEN o.from_tmsp
AND ifnull(o.until_tmsp, current timestamp)
AND o.owner <> '*STORE'

An insert trigger on the OWNER file can enforce the rule that both
the previous historical until-time and the new historical from-time will
get the same timestamp value, and that the until-time of the new row
gets the NULL value since the until-time for the current owner is
indeterminate until the next insert defining the start of the next
duration of ownership.

Also, there is an inherent problem here. BETWEEN is inclusive, so that if
the from timestamp of one period matches the until timestamp of the previous
period (as you suggest), then events with that same timestamp will be
included in both ranges.

You can get around this with date >= from and < until.

Joe



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.