Type Inheritance and Relational Theory

Appendix B

Persistence Not Orthogonal to Type

This appendix is based in part on a column that first appeared on the Database Programming & Design website www.dbpd.com (October 1998). Like Appendix A, it doesn’t have much to do with the principal topic of this book (i.e., type inheritance) as such—at least, not directly—but it does have certain implications for that topic, which is why I wanted to include it here.

I explained in the previous appendix why I felt the focus in the object world on encapsulation was a little off base. Now I want to turn my attention to another well known object dictum: namely, that persistence [should be] orthogonal to type, which I’ll refer to as POTT for short. POTT means, essentially, that (a) any data structure that can be created in a conventional application program—for example, an array, or a linked list, or a stack—can be stored as an object in an object database, while at the same time (b) the structure of such an object remains exactly as user visible as it would be if it weren’t “persistent.” For example, let EMPS be the set of all employees in a given company. Then EMPS might be represented in an object database as either a linked list or an array—among other things, of course, but let’s agree to limit our attention for now to just those two possibilities—and users will have to know which it is, because the access operators will differ accordingly.

One of the earliest papers, if not the earliest, to articulate the POTT position was “Types ...