Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newscon02.news.prodigy.com!prodigy.net!wns14feed!worldnet.att.net!24.30.200.11!news-east.rr.com!news.rr.com!news-server.columbus.rr.com!tornado.ohiordc.rr.com.POSTED!53ab2750!not-for-mail
From: Jay Dee <ais01479@aeneas.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.databases.theory
Subject: Re: Storing derived and derivable data
References: <1145622076.958951.174100@t31g2000cwb.googlegroups.com> <injqi3-q7o.ln1@pluto.downsfam.net> <1146831139.454696.295070@i39g2000cwa.googlegroups.com> <ue2ti3-u0a.ln1@pluto.downsfam.net> <1146887241.025807.311180@i40g2000cwc.googlegroups.com> <1ta4j3-tqt.ln1@pluto.downsfam.net> <BlR7g.22361$YI5.4278@tornado.ohiordc.rr.com> <gp75j3-inv.ln1@pluto.downsfam.net>
In-Reply-To: <gp75j3-inv.ln1@pluto.downsfam.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 110
Message-ID: <NcU7g.33066$P2.12034@tornado.ohiordc.rr.com>
Date: Tue, 09 May 2006 03:42:37 GMT
NNTP-Posting-Host: 24.123.195.58
X-Complaints-To: abuse@rr.com
X-Trace: tornado.ohiordc.rr.com 1147146157 24.123.195.58 (Mon, 08 May 2006 23:42:37 EDT)
NNTP-Posting-Date: Mon, 08 May 2006 23:42:37 EDT
Organization: Road Runner High Speed Online http://www.rr.com
Xref: dp-news.maxwell.syr.edu comp.databases.theory:39335

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

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.
>>
> 
> 
> The notation for specifying databases in Andromeda is here:
> 
> http://docs.secdat.com/index.php?gppn=ADD+Syntax

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.
