Extent Tables for Object ADTs
SQL3 Discussion Paper (Draft)
Sept. 30, 1993
Title: Extent Tables for Object ADTs
Author: William Kent
1 X3H2-93-384R, "Extents for object ADTs", Sept 10 1993, by John Bellemore,
Tim Nguyen, Gray Clossman and Phil Shaw.
[This is a preliminary working draft of something which I hope will evolve into a
discussion paper, or perhaps even some real change proposals. Right now it is cast in the
form of questions.]
Suppose an installation wishes to impose the following object-oriented discipline for
- Storage of object ADT instance values is managed exclusively by constructor/destructor
("c/d") routines. All other application code behaves as though their tables
contain object oid's, but not values. In effect, INSTANCE columns are accessed only by c/d
- Applications maintain object ADT data via c/d routines, and by ADT routine invocation
- The c/d routines have a range of implementation choices for configuring the base tables
in which object ADT instance values are maintained. Some examples of desirable options:
- Tables for base types only, effectively containing columns corresponding to attributes
of all types in a type family.
- Vertical partitioning by type. The Person table contains columns for attributes defined
for Person, the Student table contains columns for attributes defined for Student, etc. An
object has an entry in each table corresponding to a type of the object.
- Horizontal partitioning by subtype. The Person table contains all values for direct
instances of Person, the Student table contains all values for direct instance of Teacher,
etc. [This is a bad design if it becomes possible to be a direct instance of Student and
Teacher without being an instance of Intern.]
- Horizontal partitioning between transient and persistent instances. (The distinction
could be established, for example, by an additional parameter to the constructor routine.)
- Arbitrary vertical or horizontal partitioning within a type for various other reasons.
If instances of a type are horizontally partitioned, there might also be view defined as
the union of these tables, serving as the extent for the type.
- Possibly others.
- There should be some mechanism for providing alternative bodies for c/d routines
(perhaps a form of overloading?), allowing applications to operate with different
underlying configurations by only adjusting the c/d routines and their associated data
- Every object ADT has a corresponding extent table (preferably with the same name as the
type), which might be a base table or a view, as mentioned above. A query over the type is
interpreted as a query over this table. [It would be nice if the syntax for querying
tables and types was indistinguishable.] Thus, while maintenance of object ADT extent
tables is exclusively reserved to c/d routines, applications can still query over types.
- Are there now adequate language facilities enabling an administrator to support and
enforce such a policy? Please demonstrate.
- Wouldn't it be desirable for the language itself to enforce such a discipline?
- In either case, what specific SQL3 change proposals are needed?
4 Discussion and Rationale
We may be dealing with opposing philosophies of language design:
- Disciplinarian: a language should enforce certain good practices.
- Permissive: a language should be a toolkit allowing programmers to do whatever they
want, without imposing a "moral view".
A conservative approach is to start out with the disciplinarian view, and only relax
the discipline by expanding the toolkit and relaxing restricttions if there is sufficient
demand by actual practitioners. It will be impossible to retrofit a discipline once a
permissive toolkit is available. It's wiser to start out by giving applications too little
rope rather than too much. We can always give them more, but we can't take any back.