From: Joe Xavier (joexav@microsoft.com)
Date: Mon Apr 26 2004 - 10:22:35 PDT
This is a pretty interesting paper written in 1996 reviwing the state of databases and the introduction of object-oriented concepts in the database community.
Among the ideas discussed are:
Extended relational database systems: using user implemented ADTs written in a high level language and support for row types
- support for multi-valued attributes and inheritence
- Most of the database vendors have support for ADTs now.
- SQL Server 2005 will have support for CLR languages within the database.
- allows maintaining data independence enabling views, schema evolution
Persistent programming languages: Creating persistent data types using the type system and the programming model of OOP languages.
- In 1996 this was popular in academis but no real implementations.
Object Oriented Database systems: combine database features with an OO language.
- There are a number of difficulties in design/implementation.
- Can't create views
- schema evolution is hard
Database system toolkits/components: Creating domain-specific vertially aligned databases. - Providing specific functionality for specific applications.
- Not much work in this area.
- This is not flexible enough and requires too much expertise. Not a general DBMS.
OO Client Wrappers: Object oriented wrappers for relational database data
- QO is not covered well
- language specific
Predictions for 2006: The autors offer predictions for commercial databases in 2006
- support for ADTs in a number of programming languages. SQL Server has support for user defined UDFs, UDTs and User Defined Aggregates in SQL Server 2005 that can be written in any CLR language
- more business rules on the database than on mid-tier. Although this is not recommended, to a large extent this is achievable today on any of the commercial db's.
Overall, Object Relational databases will lead the way. OO databases are too narrow for a general dbms solution.
Critiques:
Although thepaper is thorough in what it deals with, it fails to expand on the main question - the requirement for objects and object-oriented ideas in a database. What kind of objectives are better reached with this approach.
They don't talk about how data independence is maintained in OO databases and OR databases.
This archive was generated by hypermail 2.1.6 : Mon Apr 26 2004 - 10:22:40 PDT