Re: NESTED RELATIONAL DATABASES
In article <60s5sv$ka6$1@vixen.cso.uiuc.edu>, Michael Ortega <ortega- b@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@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