Re: Storing derived and derivable data

Kenneth Downs wrote:
> Jay Dee wrote:
>
>

>>Kenneth Downs wrote:
>>
>>>dawn wrote:
>>>
>>>
>>>
>>>>Hmm.  I guess I do think about derived data as columns rather than
>>>>rows.  Other than aggregate rows, I'm having trouble coming up with
>>>>derived rows -- can you give an example?
>>>>
>>>
>>>
>>>well I said only aggregate in an earlier post, but I had forgotten about
>>>another case :(
>>>
>>>Consider a generic list of things that must be done to complete a job,
>>>such
>>>as documents required to move an animal from country A to country B.  The
>>>documents required vary by country, so you have a list of which documents
>>>are required by country.
>>
>>So, maybe an all-determinant
>>
>>   required { country, document }

Ah, Andromeda. I see.

> Lets simplify considerably and say that every job has a checklist of items
> that must be performed. The checklist for each job is taken from a master
> list at the time the job is created. Whatever rows are in the master list
> are copied to the job.
>
> Translating that into tables, we have a table MASTERLIST, a table JOBS, and
> a table JOBLIST. What is important is the table JOBLIST:
>
> table JOBLIST {
> foreign_key JOBS { primary_key: Y; }
> foreign_key MASTERLIST { primary_key: Y; }
> }
>
> which states that the table JOBLIST is composed of columns that match the
> primary key of JOBS, and the primary key of MASTERLIST, and that all of
> these columns together form the primary key of this table.
>
> Now, how would you specify something here so that an INSERT into JOBS copies
> all rows from MASTERLIST into JOBLIST?

I wouldn't. The point, perhaps not sufficiently explicit, is that some operation is needed -- which should be performed "at the time the job is created."

> I have experimented with flags on the foreign_key definitions, but never
> found anything that was totally satisfactory. At one time I experimented
> with a flag on a foreign key that basically said, "When an insert to the
> parent table of this key occurs, populate the child table with the
> cross-join of all other foreign keys". This works but I don't like it
> much. However, it is the most likely path that I will take.

And, from what I gather, Andromeda provides some sort of framework for performing designer-specified operations when some 'data manipulation events' occur, is that right?

I can see where this might be very useful, but I suspect that usefulness has bounds. And, in that regard, Andromeda is very much like many other 'interface builder' or 'application builder' or 'report builder' or even 'system builder' tools out there. I've used more than a couple, and it seems that everything works as long as you don't need anything the tool designers didn't provide features for. At that point, one has had to abandon the tool and start coding "by hand." Whether - or when - one can use the tool again has always created a point of no return decision in my development projects.

>>Notation?  '{ }' demark sets; ',' is product; '|' is where; '=' equals,
>>''' wraps literals, and '( )' enclose parameters and arguments.
>>

I took a look; I didn't see anything among the automations, chains, or cascading actions that looked like it would be a good fit. The description of automations, which seem to be column and foreign-key (a new feature) oriented, didn't seem like good fits. The phrase

   [i]t is easy enough to provide any number of ways to    add rows to TABLE X on the event of changes to TABLE Y seemed a bit of a teaser. Perhaps what you're looking for might be, in Andromeda terms, a "row automation?"

Have you asked the Andromeda authors?

> It is not related to the notation you are using.
>
> The rest of your post seems directed by assumptions that do not hold for the
> question at hand.
Received on Tue May 09 2006 - 05:42:37 CEST