Re: Storing derived and derivable data

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Mon, 08 May 2006 21:27:27 -0400
Message-Id: <gp75j3-inv.ln1_at_pluto.downsfam.net>


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 }

I think you know what I'm saying, but we are coming at it from very different angles.

Andromeda specifies everything as properties of tables, columns, or keys, because it is specifying a database. Since writing the original post I have asked myself how to specify it as a property of a foreign key.

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

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

The notation for specifying databases in Andromeda is here:

http://docs.secdat.com/index.php?gppn=ADD+Syntax

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.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)
Received on Tue May 09 2006 - 03:27:27 CEST

Original text of this message