A classification of object-oriented database systems
Authors: François Bancilhon
Venue: Proceedings of the third international workshop on Database programming languages : bulk types persistent data: bulk types persistent data (1992)

Research on object-oriented databases began in the early 80's. Activity grew in the mid 80's with projects such as O2, Orion, Observer, Damokles, etc. By the end of the decade a number of startups had been created with products on the market. There are now seven commercially available products. Most of them have been on the market for a year or two and the first users have been playing with them for some time now. Of the seven commercially available systems, only three originated from research labs while four others were the result of startups within industry. In other words, more than half the products have had little or no input from the research community. The market is not growing as fast as some had first expected it to, but it exists and is developing at a steady rate. There is a strong user interest coming from various areas (CAD, software engineering, geographic information systems, telecommunication, multimedia, etc.). The market for 1991 lies between $10M and $20M (depending on whether you count the actual sales of the seven companies or their revenues). Users are moving from the first stage of evaluation (looking at the system and playing with it) to a second stage of evaluation (trying the system on an actual application) before continuing to production development. At the end of the 80's the debate was hot between the proponents of the so-called extended relational systems and the object-oriented database community. At that time the definition of object-oriented database systems was not clear and there was some argument between advocates of this approach as to what the definition of these systems was supposed to be. The paper [Atkinson et al. 89] was a first attempt at defining an OODBS. It actually played its role in clarifying the definition and providing a pedagogical tool. It was also endorsed by all the vendors who immediately claimed that their systems satisfied all the requirements.I believe it is time to look back and analyze those systems and try to understand what they actually are and how they can be distinguished from one another. The manifesto above-mentioned is not a good tool to perform this analysis because since 1989 the technology has evolved further, user needs have been better understood through a number of experiments and actual use of the systems, and new features have been added to the systems.Competition is fierce among the vendors. The market exerts a very strong influence on the design of systems: all the vendors continually adapt their systems to what they understand customer request to be.On studying the marking brochures all systems look very much alike: they claim to do everything and solve all problems. However, when you look at them in detail and read the user manuals instead of the marking brochures they are fairly different. This does not necessarily mean that one is better or worse than the other but rather that they are the result of a number of choices and tradeoffs and that some are better adapted for some tasks and others for other tasks. In my opinion it is essential that users understand clearly what the system can and cannot deliver.As an academic I could try to analyze and compare these systems. I think this task suits better the research and scientific community. As a vendor I am no longer in this non-partial position and therefore unable to compare O2 to other systems in neutral terms. What I hope to provide here is a general vision of what these new systems are and some tips on how to analyze them. To obtain a complete analysis one should look at the actual systems and apply the methodology to them, a procedure similar to the work done for relational systems by the ANSI Relational Task Group [Schmidt and Brodie 83]. Beware, the analysis should be performed on the user manuals and not on the marketing literature. Beware also that these systems keep evolving because they are still young. Thus each system will try to evolve and add new features to palliate its deficiencies while retaining its benefits. What I propose here is a classification of the existing systems. This classification is based only on the user vision of the system and not on their implementation or architecture. I distinguish four types of systems: language-oriented database systems persistent programming languages engineering database systems object-oriented database systems.