From: "Jim Starkey" <jas@...>
Sent: Friday, July 21, 2000 12:52 AM

> In this application, a specialization hierarchy would have been
> a great simplifier. Even though the underlying implementation
> was much like a "super" table, the user visible model was
> straightforward and intuitive.
>
> We're not used to thinking about database applications this way.
> I suspect the concept generalizes well, particularly in large,
> complex databases. The only way I know to find out is to code
> it up and see if the sucker flies.

Hmmm. If I grok what you are saying then this sounds like a problem I have
worked on from time to time. We have worked and will again work on a
psychiatric outpatient system. Across the lifetime of a patient (in the
system) there are multiple contact events (when the service does something
with the client) often those contacts include the administration of some
form of assessment tools often comprised of multiple "batteries" of
practitioner rated items.

Depending on the circumstances there are different versions of these
assessment tools, sometimes long or short, sometimes sections do not apply
to a particular age group or disease, other times the first (entry), repeat
and last (exit) assessments are slightly different from each other. The
assessment tools also tend to be evolutionary and as such items are changed
across time.

Whenever I look for an elegant solution to this problem I end up feeling
like I'm trying to tie a snake in a knot. I know I could just serialize the
whole object and store it in a blob at the expense of the capacity to use
native database operations on that data but I believe it is a kludge.

Am I correct in thinking that the "Table Inheritance" discussion is leading
in a direction which might help with such problems? If so I'm all for it.

> But there are people, employees, and managers that are both similar
> and different. There are things you sell that come in boxes
> that have unit prices, discount schedules, and shipping weight.
> There are other things you sell, like licenses, that have unit
> prices and discount schedule but are completely vaporous. You
> can consider them differents objects, which complicates reporting,
> or shoehorn them into the same object.

Another project.... Trying to describe the inventory of a drug trial
laboratory where the items all need to be described as the individual
constituents of the package which is sent to doctors for application.

So, for example, doctors are delivered a batch of drugs but each item of
that batch needs to be recorded down to the individual packaging (vials, or
gelatine caps etc) boxes, instructions included, and actual active
ingredients (the drug) which might be liquid or powder or tablets or ....

Is this another example of where I might be a happy person?

Cheers
Adam Clarke
Principal
Strategic Data Pty Ltd