We are looking at moving away from a commercial RDBMS to either MySQL
(InnoDB) or Matisse. I haven't seen a good discussion on the benefits
of an OODB vs a SQL database.

My CTO and I have been discussing it back and forth. I am using
experience as a DBA/Developer, plus articles and newsgroups. He is
using Matisse product info (we are planning on testing, and he's a
very smart guy, so don't picture him as a pointy-haired-boss).


Simplicity:
---------------

CTO: It appears to be simple. The amount of time spent tuning, setting
up, etc is much lower; I am hoping we wouldn't need specialized skills
and tools to manage the database(s). Give it some disk space, and a
few other parameters, and off it goes; it never crashes, and it's very
fast.

Me: A simple interface means that if it's dead-dog-slow, the
administrator has no options to tune it. All software crashes. And a
dearth of tools means we will have fewer tools to help get the job
done. In addition, it might be impossible to write scripts to help
automate certian functions.


Performance:
---------------------

CTO: Object Oriented databases are fast. Faster than relational
databases. The way that objects are stored on disk means that
data-access is fast.

Me: I think we need to benchmark (and we will).


Reliability:
----------------

CTO: Matisse runs nuclear power plants. It sits in Cisco routers,
moving packets about. It's *very* reliable.

Me: Sure. Nuclear power plants have different requirements than we do.
Not sure how much data a router stores (it might have a database with
routing instructions that it reads; again, very unclear) but it would
have to store it in RAM - probably not more than a few megabytes.
MySQL has made leaps and bounds with reliability, and our current
commercial-database has been very reliable as well.


Object Relational Impedence:
-----------------------------------------------

CTO: We waste alot of time writing JDBC to move data between objects
and the database. That's lost productivity that we could use
elsewhere.

Me: It is time consuming. JDBC code is run-time checking; a SQL query
compiles file, but dies because there is a bug in the SQL. But there
are great, free tools like Hibernate that make it very easy to push
objects to relational databases. There are also lots of commercial
products. Still - it's kludgy to to do, and every additional tool is
more setup, more bugs, more learning.


Speed of Development:
-------------------------------------

Me: MySQL moves faster than Matisse. Already, you can find 64-bit
versions of Linux and MySQL for the Opteron (a CPU I suspect will be
highly advantageous to databases).

CTO: True.


The Matisse-SQL Interface Leaves Much To Be Desired:
-----------------------------------------------------------------------------------------

Me: We did some basic testing using the SQL interface to Matisse, and
a simple Group By made the query take minutes when a commercial
database took seconds.

CTO: They fixed that, and they are now somewhat comparible. Plus, the
SQL interface is not really the best way to talk to an OODB

Me: We have alot of SQL. We will not be able to use the OQL or talk
directly with Objects.


MySQL is Free, Matisse is Not:
------------------------------------------------

Me: nuff said.

CTO: I like free.

Me: if we use it, we should donate money.

CTO: we'll cross that bridge when we come to it.


Conclusion:
------------------

CTO: I like Matisse; I think we should test it out. And all OO
databases make the same claims.

Me: If it sounds too good to be true, it probably is. But that leaves
the door open that it might be too good to be true.

------------------------------------------------------------------------------------------------

I'm wondering if anyone out there can provide some more insight into
the differences between RDBMS and OODB. I saw a similar question (less
verbose, but similar) and someone responded with an article
(http://www.15seconds.com/issue/030407.htm) which errupted into an
argument about the author's understanding of databases (which derailed
the entire discussion). Surely someone has something more to
contribute?

Thanks in advance,
David.

Hi Puppetman !

Main Differences between OODBMS and RDBMS database:

1. Add a column to a SQL Server (alter table). At that moment all
inserts and updates will fail, because syntax of clients (OLTP) has
changed. If you have ACCESS, VB, VC++, JAVA Client, all will crash.
So Clients have to be replaced by new version ones. With OO databases,
syntax does not change, because you have to name those columns, data has
to be inserted. No break with OO.

2. If a team of programmers work together on a huge database (SQL)
application, a change in database structure will force many changes on
many places in source. I have seen projects from ibm, several german
banks, where the inner friction has increased so much, that most
programmers became very inproductive (average of 4 correct lines of code
a day) Putting more programmers into the project completely cut down any
progress. OO databases can change structure all the time, without
breaking any code.

3. OO databases can optimize i a different manner. The group in a
2d/3d/4d/5d.. hypercube in such way, that all known complex queries run
in a minimum time. They are built up hyperdimensional. After the
automatic reorganisation of all data, they run like hell. Factors of
100-3000 are not uncommon.

4. OO databases with SQL interface, like Mantisse, Cache (Intersystems)
are available, SQL interface is slow, compared to OO Interface.

5. Programs, which work together with SQL databases, have to copy some
data into ram, then do something and restore into SQL. OO databases have
hibernation ( persistence of data ), java code directly works from and
onto database sets. No copy of any data is required (to be more precise:
the programmer does not have to care about syncing data !). See:
http://hibernate.bluemars.net/ This feature only can be used from OO
programming languages, like Python (http://sourceforge.net
/projects/modeling/, Ruby, JAVA, .NET Languages)
Object - Relational Bridges exist.

6. OO Databases have something like MVCC in SQL Databases. Every dataset
has its own version number, so there are any collisions at all, a
programmer has to care about (table, row locks). Code can be kept much
shorter, cleaner, cheaper (about 1/3 of conventional development costs)

7. Software development is expensive. Tools, which use UML for modeling
application frontends, database structure exist. With Rational Rose you
simply draw data structures, workflow (graphs) for about one year, then
you click on a button, and you have 300.000 lines of code for your
servlet, 200 x 5000 lines of code for your data insertion masks as java
Applet in your browser. Then you can fill up some logic in java classes
and your project is finished. With changes in your database structure
there is no need for your programmers to change their code. Rose knows,
where to change. Just one klick and you have 100.000 lines of code
changed. The inner friction of software development is zero. Huge
programs cannot be made without Rational Rose. Look out for 5GL code
generators. Programmers do never ever have to care about SQL,
interfaces, locks, transactions and so on.

8. It's a pity, that nearly no one has already understood, how fast
software development can be, how cheap software maintenance, refactoring
costs can be zero.

The advantage of OO databases is only tremendous, if you have a UML
tool, a integrated code generator, a persistent OO Interface to a OO
database. If not, standard 4GL tools will perhaps be faster.

Borland (Inprise) and IBM Eclipse with rational rose have such
development tools. Borland ist much cheaper....

Choose you toolkit with care, there is no way of return.

Your arguments below are quite nice, but do not hit the ball.

regards, Guido Stepken


puppetman (AT) somewhere (DOT) com wrote:

Guido Stepken <g.stepken (AT) t-online (DOT) de> wrote:

This is slightly out of context. Hibernate is an "old school" (for you
relational theorists: stupid and useless) O/R mapper. It is not really
related to "hibernation" which in turn I've never found in combination
with "persistence of data".

--
Christian Bauer

"Hibernation' is one of the ways in which animals adapt and survive the
cold winter months. In many ways, it is like a very long, deep sleep.
When learning about hibernation, it is easy to get confused. Scientists
and biologists disagree on what the word hibernation really means."

There is a freshmeat project, which describes "suspend to disk" as
"hibernation".

I thought it was a good idea to follow the autor of
hibernate.bluemars.net to set hibernation equal to "O/R mapper" with
persistence of data, because the objects in j2ee, jboss are kept in
containers, which normally are persistent data sets. Functions work on
data, which reside in containers. A OO database is automatically
accessed, when data in a container is opened. To care about such things
as <<open, select, *change* insert or update, close>> have become
unneccessary. Simply access an object, don't care about, where it is
stored. By the way: This is, what SUN all the time wants to explain,
nobody understands.

regards, Guido Stepken

Christian Bauer wrote:

In article <bgo1fv$1su$05$1 (AT) news (DOT) t-online.com>, g.stepken (AT) t-online (DOT) de
says...
I do this every once in a while without the RDBMS system failing.
Maybe your coding practices are the problem? Or, is this just blatant
hyperbole?

This will happen anywhere, be it OODBMS or RDBMS. It doesn't
matter what the system is, add a new attribute/property and the
knowledge must be spread through the apps to be used properly.

Again, I can do the same when I work in an RDBMS.

Huh? "Hyperdimensional"? Please define your use of this term and
also add how a relational database is non-"hyperdimensional".

This is not a problem with RDBMSes, but with the SQL interface in
an OODBMS product.

This is one of the few true advantages of an OODBMS. Seamless
persistence. However, the objects define the navigation in data, so you
are locked into your design sometimes.

Huge != good. Also, there are generators for RDBMS-backed systems
that can generate reams and reams of code too.

----------------------------------------
Paul Tiseo, Systems Programmer
Research Computing Facility, Mayo Clinic
tiseo128.paul23 (AT) mayo (DOT) edu
(please remove numbers to email me)

By accepting Matisse's marketing propaganda at face value, your CTO sounds
more gullible than intelligent; he is certainly badly misinformed. By
posting your question on usenet, you are only inviting uneducated kooks like
Guido to make up fantastic stories to support their misinformed fanaticism.

You and your CTO know your business better than anyone on usenet. If you
both understand the difference between data management and file processing
and if you both know the decades old arguments for and against the network
and relational models, you will be able to determine your business needs
easily.

<puppetman (AT) somewhere (DOT) com> wrote

Hi Paul !

http://tumb1.biblio.tu-muenchen.de/p...0/blaschka.pdf

Search for "MOLAP" in Google to find engl. descriptions.

Hi, Paul !

OO Databases are built up in a quite different manner:

1. Define a layout of a object, a class.
2. Define a attribute, say price: class.price
3. Invoke a instance: a = new object(class)
4. a.price=5$, b.price=3$
5. add two objects: a.price+b.price
6. add a new attribute: a.size (or redefine its class:
class=class+class.size)
7. search for all objects where size is large -> zero objects found
8. add attribute size to all objects a,b: a.size=huge, b.size=small
9. search for all objects where size is huge -> a.

Objects can contain other objects, you can let grow your business like
you want. At every time you can add more attributes, delete some,
change, without breaking any code. If you define a behaviour of a class,
what to do, if a attribute doesn't exist any more, or a attribute is
added, (error exception) no code will break.

Whereas in RDBMS databases the attributes define a table and objects are
in the table, the OORDBMS defines a class, invokes a instance and then
adds some attributes to a single instance or even at a class, so it will
change all instances at a time (redefinition of a class).

The OO design is much more flexible and has much less friction within
the programmer team, than all RDBMS designs.

Learn python and http://modeling.sf.net, a very good insight in OO
modeling for old RDBMS specialists. I promise you, you will never ever
go back to RDBMS designs.

regards, Guido Stepken

In article <bgpmt0$d4d$01$1 (AT) news (DOT) t-online.com>, g.stepken (AT) t-online (DOT) de
says...
Generally, yes. Most commercial RDMBSes are, physically, SQL
DMBSes that might or might not have full relational capabilities. OO
DBMSes suffer from the same problem. They usually have even less
relational capabilities that SQL DBMSes.

One of the main problems throughout your posts is confusing the
physical benefits of an object persistence mechanism with being
mututally-exclusive with the logical benefits of the relational model. A
relational layer (in terms of what relational concepts allow you to do
with data, not in terms of an SQL DBMS and O/R mappings) can sit over a
physical object persistence layer. That is what many OODMBS vendors have
found necessary to try to acheive.

Same with RDBMSes.

Same with RDBMSes.

Well, the code for the behavior "breaks". At any rate, I can
similarly change behavior in an RDRBMS-backed system without causing
anything more than the immediate behavior relying on a piece of data
from breaking.

According to my limited knowledge, this is one of a handful of
ways to store objects in a relational database, and perhaps not the best
way.

When I add a column, I redefine all "instances" too, assuming each
record is an object, as per your recommendations.

One possible advantage is that of lessened friction with
developers. However, is it neither generally more, nor less flexible.

I know Python, and many other languages. I am a developer.
However, I am also smart enough to realize that the relational model
confers immediate and long-lasting benefits that one should always have
in any database, irregardless of how its physical storage is executed.

----------------------------------------
Paul Tiseo, Systems Programmer
Research Computing Facility, Mayo Clinic
tiseo128.paul23 (AT) mayo (DOT) edu
(please remove numbers to email me)

I still do not agree. With Python i program and build up complex data
structures. Then i take shelf Module and dump all data to disk, simply
tell the database, what so search for. Persistence is implemented in
several minutes, using a shelf module, writing all complex data to disk
is 4 lines to add then.
With normal programming languages, i SQL databases do not automatically
change structure, when i change code. I have to know SQL structure
beforce, have to program buffers, which can hold the result set of a
query, and have to care about re-synchronisation of buffers with SQL Server.
With OO programming and OO database i simply design data models and dump
this structure simply onto a OO database, which changes even structure,
when old data ist still in the database.

regards, Guido Stepken

Paul Tiseo wrote: