Re: Clean Object Class Design -- What is it?

> I don't really have any argument one way or another, as far as what
> system people choose to use. If an OO dbase does the job better and
> quicker, use it.

First, you would have to have to have some reason for thinking that it could do either.  

> But, for that matter, I might find a case where I could use an array
> to do database-like work and not need to go through SQL in a given
> application. If it works, of course I'd use it. Or a linked list or
> hashtable or whatever. At times, using a major database program would
> just be overkill and the overall performance of my application would
> be much worse than if I had taken the simpler approach.

In your application, use whatever you need. If you do not need a DBMS, don't use one.

If you need a DBMS, you need a relational DBMS regardless whether you realize or accept it.

> An existing database system, any of the major commercial ones, is an
> attempt to fully implement SQL

You are deluding yourself. The commercial strategy involves making sure the SQL standard considers the current implementation compliant without further development.

> SQL is an
> attempt to present the logical language behind any data storage and
> retrieval system in a rigorous way.

Again, you are deluding yourself. SQL is anything but rigorous, and no attempt was ever made to make it so.

> Mapping a complete branch of
> information theory to a practical working computer system is going to
> be difficult, if not impossible, so shortcuts are taken.

Shortcuts are taken because the programmers involved do not think through the consequences. The shortcuts actually make the task much more difficult, if not impossible.

> Even with shortcuts taken though, a really substantial implementation
> of SQL is going to be very resource-intensive.

Really? If that is the case, how can a single programmer working in isolation develop a small-footprint DBMS that supports dynamic SQL, embedded SQL, static execution paths and even has a good optimizer?!?

> The nature of the theory is just not necessarily going to be practical
> to implement completely in an electronic system.

The nature of the theory is completely practical to implement. The stupid attitude that theory is impractical causes the impracticalities.  

> And, for that matter, most databases in practice are not going to be
> 'perfect' implementations of their theoretical representation.

Of course not, pi has an infinite number of digits, and all the bits in all of the computers ever built and ever to be built is a finite number. In fact, all of the possible states of all of the bits of all the computers ever built and ever to be built is a finite number.

> It's not that the developers are 'bad', it's just practicality.

The cause is not practicality. The cause is the poor quality of the dbms product. Until people drop this idiotic attitude that theory is impractical and start actually demanding quality from their vendors, they won't ever get sufficient physical independence to allow for full normalization. In the meantime, we all have to live with compromised integrity.

> I don't think an 'OO Database' is really a different animal than a
> 'Relational database' though. I guess that's my point. It's just a
> different way of implementing it.

Relational DMBSs are OODBMSs. However, what most consider OODBMSs are merely network model databases with added complexity. In fact, precious few so-called OODBMSs are even DBMSs.

> As others have said in this thread, a relational database -is- an 'OO
> system'. Personally, I would map the object classes to the tables,
> each table should be a class, and the object instances to the records.

And you would be making a major, albeit common, mistake. You are mapping a set of objects (a tuple) on one side to a single object on the other. You are mapping meta data (object class) on one side to data on the other -- or more exactly to a set of data (relation).

> In purely theoretical terms, I don't think there's -any- real
> separation.

I do not know how anyone could possibly hold this position.

For starters, relations are explicity unencapsulated while objects are explicitly encapsulated. A relation is data while an object class is meta data. Relations have operators that result in relations while object classes do not have operators that result in object classes. etc. etc. etc. Received on Tue Jul 10 2001 - 02:54:20 CEST