Re: S.O.D.A. database Query API - call for comments

On Mon, 14 May 2001 12:21:11 +0200,
"Carl" == Carl Rosenberger <carl_at_db4o.com> wrote:

Carl> From what I have learned about relational systems, choosing a primary
Carl> key that does model something in the real world, is bad practice, since
Carl> you run into terrible trouble, if the used system changes in the real
Carl> world (e.g.  changed employee id pattern).

true, but public identifiers that behave more or less like primary keys are a fact of life (even though in most cases you shouldn't use them as real keys in a database).

Carl> "Existing links" are defined by the class schema of the application.

which is a bit rigid ... you can't do tricks like finding the gaps in a series of entries (see other thread) by doing a self join. One can argue that this is hack, but in practice, such hack often save the day, in day-to-day data management.

Carl> You are trying to use the deficiencies of relational databases as an
Carl> argument for them:
Carl> - Relational databases need multiple tables to represent inheritance
Carl> hierarchies. Queries tend to get lots and lots of joins. The access pattern
Carl> becomes very difficult to understand.

you don't always _have_ to build complex joins if you don't want to; you have the _possibility_, which brings great extra speed (far fewer round-trips) and extra power (sophisticated queries and aggregates functions).

Carl> - With object databases you can query against a single object class, no Carl> matter how deep the inheritance hierarchy is.

So you can with RDBMSs, at the expense of expressiveness.

Carl> Provided that you work with modern programming languages, relational
Carl> databases require you to work with two programming paradigms:
Carl> - object-oriented in your application class model
Carl> - relational in your database scheme

Carl> Using two paradigms makes an application more complex.

But this presupposes that you can treat the data and the 'business logic' as one unit, which is highly debatable. It does make sense to decouple storage and business logic. Application object attempt to roll the data and the logic into one, which is useful for the application programmers, but you loose a substantial amount of data manageability (malleability) by insisting that data adhere to the objects.

Carl> This will result in
Carl> - more errors

arguably, because there is code to maintain. But several writers have attested the nightmare (or impossibility) of schema evolution using an OODBMS, so the trade apears to be

  ease of application development vs. adaptability of schema

or put negatively,   

  rigidity of schema vs. having to maintain a mapping

Carl> - more implementation work = higher cost

no: you keep the data management more isolated (orthogonal) from the application logic, which makes the data more usuable in the future.

Carl> - worse performance

for a very limited class of queries, yes, perhaps. For all others, RDBMSs seem to perform nicely, or much faster (through the lack of round trips), and offering much greater power. And just to repeat my self, for properly indexed tables, the speed of a join is O(R + S), R the number of resulting rows, S the number of rows in the smallest table. It does not depend on the number of tables or total numbers of rows.

Carl> ...and of course more misplaced data.

?

>> Normalizing the database greatly improves
>> the ease of extension.

Carl> No.
Carl> You have to extend two models:
Carl> - the application class scheme
Carl> - the database table system

Carl> You also have to correct all queries and mappings

yes; that's inevitable (although large parts can be automated). How are you going to do this in an OODBMS ?

Carl> by working through all applications by hand.

No, of course not: you have one object layer, and all the application code uses just that. You only have to adjust the object-relational layer.

And BTW, much of this can be minimized by having the object-relational layer access the RDBMS mostly thru relational views. Views offer a device to avoid changes in the schema (like (de)normalization, or schema evolution) affecting application code; they can buy you precious convenience and time, which is simply unavailable in an OODBMS system.

                                                                      Philip

-- 
If you have a procedure with 10 parameters, you probably missed some. (Kraulis)
-----------------------------------------------------------------------------
Philip Lijnzaad, lijnzaad_at_ebi.ac.uk \ European Bioinformatics Institute,rm A2-08
+44 (0)1223 49 4639                 / Wellcome Trust Genome Campus, Hinxton
+44 (0)1223 49 4468 (fax)           \ Cambridgeshire CB10 1SD,  GREAT BRITAIN
PGP fingerprint: E1 03 BF 80 94 61 B6 FC  50 3D 1F 64 40 75 FB 53