VODataService becoming WD, then PR

Paul Harrison paul.harrison at manchester.ac.uk
Tue Nov 18 03:49:38 PST 2008


On 2008-11 -18, at 10:06, Gerard wrote:

> A TAP inspired example could be the Database<-Schema<-Table<-Column
> relations in the TAP_SCHEMA,
> ff this were modeled as follows
>
> TAP_SCHEMA.databases
> name
> ...
> primary key(name)
>
>
> TAP_SCHEMA.schemas
> database_name
> name
> ...
> primary key(database_name, name)
>
> TAP_SCHEMA.tables
> database_name
> schema_name
> name
> ...
> primary key(database_name, _schema_name, name)
>
> TAP_SCHEMA.columns
> database_name
> schema_name
> table_name
> name
> ...
> primary key(database_name, _schema_name, table_name, name)
>
> Fore xample TAP_SCHEMA.columns has a foreign key (database_name,
> schema_name, table_name) to tables,
> (database_name, schema_name) to schemas and database_name to databases
> This further complicates a column-level definition of the foreign key.



Yes - so I think that my attempt to do this with a single extension  
attribute on the TableParam is beginning to stop being "simple". It  
would be necessary to have a list value for the fkey.

e.g. on the TAP_SCHEMA.columns.database_name column
fkey="tables.database_name, databases.database_name"

and similarly on the other columns that make up the key.

This I think leads us to wanting to go with Gerard's suggestion, which  
is effectively a reintroduction of a (better) tableJoin element that  
had been previously dropped. I also prefer the idea of having the  
ForeignKey defined as a child of Table.

Cheers,
	Paul.




More information about the registry mailing list