Extent Tables for Object ADTs

References:

1 Introduction

2 Desiderata

Suppose an installation wishes to impose the following object-oriented discipline for SQL programming:

• 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 routines.
• Applications maintain object ADT data via c/d routines, and by ADT routine invocation and assignment.
• 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 definitions.
• 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.

3 Questions

• 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.