Re: NESTED RELATIONAL DATABASES

In article <60s5sv$ka6$1_at_vixen.cso.uiuc.edu>, Michael Ortega <ortegab @uiuc.edu> writes

[Thread discussing when an ORDBMS ceases to be relational, touching on the issue of row pointers, nested tables (Oracle 8) etc., and the following...]
>Jeremy Rickard <Jeremy_at_jbdr.demon.co.uk> writes:
 [snip]
>>This was to do with the object extensions, which I'm all for, but
>>believe emphatically that they should be handled in a modular, "black
>>box" way.
 

>>Specifically, only the UDFs, and NOT the core RDBMS, should be "aware"
>>of the structure of the non-atomic datatypes. Otherwise, before you
>>know it the optimiser will be changed to handle elements in non-atomic
>>types and you might as well call the thing "nested relational"!
[originally we were talking about UNIDATA Pick, a so called "nested relational" database]

>While I agree with most of what you say, I think the core should
>have some knowledge about the structure of the non atomic type.
>I agree that at the data modeling level, the core should be kept
>as far apart as posible, and it should appear like this to all
>users. The DB admin and the optimizer however should be exposed to
>this structure exactly to effectively support these data types.
>A concrete example where this would be useful is with a new indexing
>method (say Rtree in Informix aka Illustra). You want the optimizer
>to be aware of the internal structure of your type. This however should
>only be exposed to db admins and "expert" database developers (not
>application, but DBMS developers).

I am most familiar with DB2. It allows you to specify the CPU and I/O costs of each UDF in some detail, so the optimiser would have a very good idea of the *cost* of functions, and would not really need to understand the internals of the UDT for that particular reason. This seems a natural and sensible solution.

Regarding the indexing however, you seem to have a very good point. I do not know whether or how DB2 and other DBMSs manage the creation of indexes for extended types in a modular fashion that does not blur the line between DBMS core and the UDT/UDFs. One possible solution would be to use triggers and appropriate index-maintaining UDFs?

-- 
Jeremy Rickard