Re: Storing derived and derivable data

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

So, maybe an all-determinant

   required { country, document }

would allow you to know what country requires which documents and what document is required by which countries. I guess a

   jobs { job }

is needed. In no particular language, some operator('job','country') should do

   { jobs | 'job' = job } , { required | 'country' = country }

which is supposed to yield a set of { job, country, document }

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

"But, Shirley, was that really your question?"

> When a job is created, you want to COPY all of the rows for Country B into
> the JOBS_DOCS table. The user can then override these defaults by deleting
> or disabling some rows and adding new ones, but the original copies came
> from the master list.
>
> How do you describe this copy command? Right now I do this in the client
> code (gasp!) It's on my list of things to think about someday.

Copy command? No doubt, you want to do something with the response - throw away the country and put the rest it in the job-docs table; seems fine by me - but I'm not sure it's a copy.

Created? You *are* thinking client code, aren't you? Nothing wrong with that, but a different frame of mind will serve you better when there are data to be wrangled. Received on Tue May 09 2006 - 02:27:13 CEST