VODataService becoming WD, then PR

[Doug Tody]

Hi All -

I haven't had much time to get involved with this discussion in the
past several days, but will just state that I have always favored
defining the foreign keys as the best method to advise the client to
help plan joins.  The proposals look reasonable but I need to think
about it more carefully to have a more definite position (I am off
in a workshop the rest of this week).

Regarding native SQL datatypes, this has been suggested before for
inclusion in the TAP schema (and VODataService), and would be easy
enough to do, however since table transport is based upon VOTable
providing the column type mappings using VOTable types is the
primary requirement, and is DBMS neutral.  SQL datatypes tend to be
DBMS-specific so if we did support this we would have to decide whether
to merely pass through the native SQL datatype namess, or possibly
map them to something more general such as JDBC types.  For example
see http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html
Although this is somewhat Java-centric, the problem addressed is
general and the approach allows a client to be more DBMS-independent.
Or maybe we should just pass through native types.

On Tue, 18 Nov 2008, Gerard wrote:
> Maybe again for a possible TAP extension:
> Should/could indexes be included in the metadata for a table?
> When composing queries it is often very useful to know what indexes exist.

This is already included I believe (it was discussed when we negotiated
the most recent TAP schema and VODataService).  What is currently
proposed is not a full specification of indexes, but an optional
per-column flag indicating if that particular column is included
in an index.  IRSA for example currently does this, hence we have
an existing use case where this has been found to be sufficient.
Plus it is simple.

	- Doug