You would want a typed table if data particular
to a row took that form. Where you would want
something like a 2-D array which was *queryable*.
You could achieve the same effect by using a foreign
key.
In postgres and Illustra, references were possible.
That is, storing the OID (REF) of a table in a column of another
table achieving the same effect. SQL syntax support
was needed for the REF type. I believe this was removed
or suppressed in PostgreSQL.
It could be a violation of relational database design
if used improperly. Codd's rules say nothing about
nested structures. If the data in the column.table
was not unique to the row in question, then it would
violate the normalization rules. But this is true
of any data. Data is data.
An ORDBMS is type blind where ever possible. That means
a table in a column is just data. The only thing that
makes it different is the additional SQL syntax to support access.
elein
On Thu, Jun 03, 2004 at 04:09:51PM -0700, Josh Berkus wrote:
> Elein,
>
> > A typed table is an type which happens to be
> > a table. They are also known as composite types
> > or row types.
>
> Well, Tom was working on this for spec compliance. I don't know if he
> completed it.
>
> Of course, it doesn't answer the two corrolary questions:
>
> 1) Why would one want a typed table?
>
> 2) Aren't typed tables a big violation of relational database design?
>
> --
> Josh Berkus
> Aglio Database Solutions
> San Francisco
