Re: OO versus RDB

Bruno Desthuilliers wrote:
David Barrett-Lennard wrote:
Bruno Desthuilliers wrote:

(snip)

Well if you want to implement a software solution to a given problem
you need to make some decisions.

And ? I do write softwares, and most of them uses both an OO language
and a RDBMS.


Not entirely sure what the issue is.

You said "most" (but not all). Therefore decisions have been made, or
did you just toss a coin?

Instead of trying to be funny, please take some time to understand the
implications of the fact that there exist applications that are written
using the OO paradigm *and* uses a RDBMS. One of these implications is
that OO and RDBMS are *not* mutually exclusive. Which makes your
"proposition" useless and irrelevant.


You misunderstand me.

That's very possible.

A complete system can be decomposed. One sub-system can be solved
using OO. Another can be solved using RM. My criteria relates to what
parts or "aspects" should use OO and what parts or "aspects" should use
RM.

OO being about processing and RDBMS about data management, this is quite
a no-brainer.



Isn't a more formal criteria useful? My aim is to come to a deeper
understanding of why OO has not displaced RM in certain domains.

Because OO is a general purpose programming paradigm, and RDBMS are
systems to manage relational data. Apples and oranges.


They are apples and oranges but they are both able to store
information.

The OO paradigm has nothing to do with "storing". Once again, it's about
*programming*. Persistance is a totally orthogonal problem.

I don't agree. OO provides a methodology for storing data (as well as
processing it). You can choose to avoid RM completely.


The OO extremists think that RM is total unnecessary.

And the RM extremists think that OO is totally unncessary too. And both
are right : neither RDBMS nor OO (nor FP, nor even structured
programming FWIW) are "necessary" - one can always program in assembly
or machine language and use flat files. It's just a matter of
convenience. RDBMS can do all the hard part of data management, and OO
(may) help managing code complexity. Somewhat orthogonal concerns.
Apples and oranges...

If you are given a problem that already stores information in
relational form the decision has already been made for you. However
that is not always the case. Hence you need to decide how to store the
information

With an OODBMS you have more options of avoiding RM completely, because
the OODBMS handles persistence and transactions for you. It even gives
you query support. Objects are faulted into memory on demand as
pointers to objects are dereferenced.

I know what's an OODBMS, I frequently work with Zope and the ZODB. But
what an OODBMS stores is (part of) the state of an object, not the
object itself.

Oh really!

In any case an OODBMS is able to persist an arbitrary graph of objects.
The structure on disk is in direct correspondence with the OO
structure in memory. ie unlike an RM it is denormalised.

The upshot is that the OO paradigm or methodology or what ever you want
to call it, provides a means for storing your data.

If you don't agree with this, then that merely indicates that you have
a different definition of what counts as OO. A difference in
terminology can mean we appear to disagree. I don't mind your more
restrictive definition of OO. You are entitled to it. However, I do
mind that you don't take the time to account for such differences.
Instead you assume from the outset that you are right and I am wrong.

A good question is : why hasn't OODBMS displaced RDBMS in the business
domain?

1/ interoperability (language-independance problem...)
2/ pre-existence of RDBMS
3/ good adequation between the relational model and business data models

FWIW, RDBMS have been somhow tailored for business apps. No surprise
they are heavily used in this domain.

Perhaps. But maybe it (also) involves the subject of my original post.

It
mostly seems to be in Business domains, where we need to store
information *about* things.

When I write documentation for one of my programs, I do store
"information about things" somewhere - but not necessarily in a RDBMS.
Now program documentation is not really relational by nature...

OO is not about "storing" anything - it's about how to design a
*program*. RDBMS are about efficient management (organisation, querying
and storage) of *data*. Apples and oranges...


Don't agree.

You have the right not to agree with reality. But this is usually not a
good sign.

OO is often the right choice for storing something.

This has strictly no meaning. OO is about behaviour, not about storage.
I can read/write the same text file from a procedural C program, an OO
Python program or a FP Haskell program. The text file itself doesn't
care, and the same underlying system calls will be used. The only thing
that will change is the language-specific way to deal with files.

For
example, I wouldn't try and store a text document (like a Microsoft
word format) relationally.

This has nothing to do with OO, it has to do with file I/O. And FWIW I
never said I would use a RDBMS to store text documents...

Our difference of opinion mostly relates to terminology. You have a
narrower definition of "OO" than I do. You say it is restricted to
"processing", but not data that may persist. I do not.



OO dominates lots of other domains like
image processing or GUI development.

Behaviour. You don't 'store' GUIs nor image processing. Apples and oranges.


By 'store' you mean persist?

Images often need to persist.

Images are *data*. You were talking about image *processing*. You don't
store processing - at most the *result* of it. Do you understand the
difference between data and processing ?

It is common for image processing applications to need to store data.

Again, you lock onto your particular interpretation of what I say (ie
"image processing domain") and on that basis assume I'm wrong and you
are right.

I would definately store a terra-byte
multi-res image in an OODBMS rather than an RDBMS.

I would definitively store it on the filesystem.

I have stored multi-gigabyte multi-res images in an OODBMS and it works
very nicely. The quad-tree structure of tiles would have been
pain-full to store directly in files because I would need to worry
about lots of additional problems like an LRU cache for the tiles, etc.


I would store a scene graph in an OODBMS rather than an RDBMS.

If only your OO program has to use this data, then choice is yours...


I don't believe the need for persistence is the answer.

It's only part of it. We also need to enforce data coherence, handle
concurrent access and atomic complex updates - and of course have a
quick, reliable and flexible way to retrieve data. And - for most
'business' apps, to share them between different applications, most of
the time written in different languages, and quite commonly running on
different machines. RDBMS do have limitations, but there's still the
best tools I know for such use case.


It is more
subtle than that.

RDBMS are about managing relational data. As the name implies... I don't
see anything particularly "subtle" here.

It's not subtle after the decision has already been made to store the
information relationally.

This decision is (well - should be) led by the intrisic nature of the
data and the way you intend to use them.


Now I have another question for you : why RM has not displaced other
data management tools in certain domains ?

I suggest because of my criteria !

Sorry for being dumb, but which one ?

The subject of my original post.

Cheers,
David Barrett-Lennard

.

Relevant Pages

  • Re: OO versus RDB
    ... and most of them uses both an OO language ... using the OO paradigm *and* uses a RDBMS. ... They are apples and oranges but they are both able to store ... With an OODBMS you have more options of avoiding RM completely, ...
    (comp.object)
  • Re: OO versus RDB
    ... using the OO paradigm *and* uses a RDBMS. ... They are apples and oranges but they are both able to store ... With an OODBMS you have more options of avoiding RM completely, ... You don't 'store' GUIs nor image processing. ...
    (comp.object)
  • Re: SQL
    ... Language can and do this. ... SQL is typed, ... How about something from the domain of custom biz apps. ... yet nobody would even try to use RDBMS for that. ...
    (comp.object)
  • Re: OO versus RDB
    ... Because OO is a general purpose programming paradigm, and RDBMS are ... They are apples and oranges but they are both able to store ... Nothing about persistence here... ...
    (comp.object)
  • Re: OO versus RDB
    ... Because OO is a general purpose programming paradigm, and RDBMS are ... They are apples and oranges but they are both able to store ... I know what's an OODBMS, I frequently work with Zope and the ZODB. ...
    (comp.object)