Re: Contexts (was Classes vs. Instances)

[Avril Styrman <Avril.Styrman@helsinki.fi>]

Rich,

even though views could be used to define types, the object-oriented 
way of doing this with an editor would be much quicker. It is just
easier to press plus-button and give a name for the sub-table and 
add a couple of slots for it than to create views and to explicitly 
define relations of the views, and to join columns of tables. Perhaps 
I just haven't confronted an SQL editor with which this can be done 
as easily as with a basic ontology editor. 

> So what exactly could be added to SQL to make types any more useful
> there than the standard tables, views and procedures?

If views were used to define types, there should be a detailed 
convention of how to use the views specifically for that task. If 
views were used in type definition, views could not be used in 
anything else. Maybe there are so many ways of using the views (?) that 
a convention could no be reached. In this case, another feature should 
be added to SQL: the reserved subTableOf property for all the tables.  
Only automatical functionality would be added to SQL editors: a 
subtable collects all the columns of its supertables. There would not 
be problems with stacks that you mentioned if SQL would remain 
othervise the same.

Think how many hours the IT society would win if SQL databases 
were planned in an object-oriented fashion. 

Avril


Quoting Rich Cooper <rcooper15@comcast.net>:
> Any frame can be implemented as a view, perhaps of multiple tables.  To
> use
> multiple types (classes) in a frame, simply combine the tables with the 
> proper
> join expressions and zot - you have a frame.
> 
> When the industry found out that relational SQL databases were so
> useful,
> people naturally jumped to the conclusion that object-oriented databases
> 
> could
> go yet one better by adding types of a higher level of abstraction.  As
> you 
> may
> have noticed, it didn't work.  That's because object-oriented programs
> use 
> stacks
> to keep the objects straight, but persistent storage systems like SQL
> don't 
> have
> any use for stacks, except in stored procedures, where they are dynamic
> data
> structures, not persistent tables.
> 
> So what exactly could be added to SQL to make types any more useful
> there
> than the standard tables, views and procedures?
> 
> IMHO, SQL has reached its major advances already.  More built in
> functions,
> a little improvement in domains (blobs should already have been
> supplemented
> with JPEGS, files, even databases as domains, but for some reason this 
> hasn't
> happened yet).
> 
> If anyone can suggest an improvement to SQL in detail, I would be very
> receptive.
> 
> Rich