Hi all, I have limited knowledge when using OR features of SQL - especially concerning embedding objects as types. I just wondered if anyone could point out to me some of the potential drawbacks of using OR features, especially in regard to querying, schema evolution and defining data structures.

kind regards

Andrew (FAC51)

In my mind, there are three different classes of database engines for this question: engines that are object based, engines that use SQL without extensions to support objects, and engines that use SQL that have object oriented extensions.

In an object based system, such as Eifel, SmallTalk, or MUMPS the question is moot since all you've got are objects. These tools usually bolt "data storage" onto an object framework. I don't know of a truely object oriented database that performs well enough for production commercial use, but there were some really promising possibilities a few years ago that might still come to fruition.

SQL engines without significcant object extensions are the "workhorses" of the database world. I'd estimate that they do 95% of the database work in today's world. These engines are usually based on nearly pure relational algebra. This makes them a poor fit for object oriented queries, since many of the key features of object orientation like inheritance and polymorphism are difficult to represent using relational algebra, and are practically impossible to implement using the syntax supported by most of these engines.

This leaves the field pretty much "wide open" for the SQL with object extensions group. These engines all do things slightly differently, and all suffer from trying to exist in two worlds at once that seem to be more or less incompatible. There is a lot of promise, but so far I haven't seen anything that does what I consider to be a good job of bridging the relational and object oriented worlds.

-PatP