Re: OO versus RDB

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

David Barrett-Lennard wrote:

(snip)
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

Oh yes ? Chapter and verse, please ?

(as well as
processing it). You can choose to avoid RM completely.

Like you can do with any other programming 'paradigm'.

(snip)
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.

And ?

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

Total non-sens. What provides "a means for storing [my] data" is a
Python library named ZODB, not "the OO paradigm or methodology or...".
And FWIW, with RDBMS, it's not the "Relational model" that provides a
mean to store data, but some RDBMS program. If you can tell theory from
implementation, then you have a serious problem.

You have a rather amusing nature! Honestly your posts entertain me!

I'm learning that you lock onto individual words or phrases within a
sentence, take its meaning very literally, and don't allow context to
get in the way. For you "X provides a means for storing your data"
means one thing and one thing only : X is the thing that writes the
bytes to secondary storage. The idea that X be "A way of thinking" or
"paradigm" doesn't occur to you even though that was the sentence you
were given.

Furthermore, you seem to assume "store" always means persist on
secondary storage. Note that it is quite conventional to say "store in
memory".

I'm also trying to work out your assumptions on what "data" means to
you.

If you don't agree with this, then that merely indicates that you have
a different definition of what counts as OO.

Yes : I use the most commonly agreed upon definition : OO is about
objects (defined as 'identity + interface + state + behaviour') sending
messages to each others. Nothing about persistence here...

A difference in
terminology can mean we appear to disagree. I don't mind your more
restrictive definition of OO.

"More restrictive" ? Lol.

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.

I do assume that your definition of OO - whatever it may be, since you
didn't even bothered exposing it - is wrong, since it leads you to
absurd statements like "OO provides a methodology for storing data". OO
provides a way to organize code. period.


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.


My my my...

(snip)

Our difference of opinion mostly relates to terminology.

Since almost everyone here disagree with your terminology, you should
perhaps consider your terminology as inadequate.

You have a
narrower definition of "OO" than I do. You say it is restricted to
"processing",

It is.

but not data that may persist.

"Data that may persist" are not objects - they are data. The fact that
once may use these data one way or another to (re)construct an objects
graph doesn't make the data "objects".

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.

And ? Please explain the fundamental difference between writing data to
a file from a procedural language, an OO language or a functional
language ? Will the binary file be different ? Strange enough, when I
write a text file from a Python program, I have no difficulty reading it
from a strictly procedural C program.

Let me describe a scenario that helps to illustrate what I'm saying and
my choice of terminology.

In C we can *store* data structures in memory (let's just call it
"data"). This uses the simple types like float as well as user defined
structs. Members can be embedded by value or referenced by pointer.
Arrays can also be used. Now let's suppose we want to store a CAD
drawing, and we decide we need an inhomogeneous group of graphics
elements. Now this is C, not C++ so we can't just define an abstract
base class and use polymorphism. Instead, we heap allocate each
graphic element (because they vary in size) and store an array of
pointers to them. Each element stores its type, so when we iterate
through them we can switch on type in our procedural code. Let's
suppose we use the composite pattern to allow arbitrary nested
grouping. Suppose this CAD drawing needs to persist. We choose to
write procedural code that recursively serialises all the data to/from
a given file.

What do we call this methodology for "storing our data"? I don't refer
to the procedure that merely serialises the data to disk. Remember
that the word "store" doesn't imply persistence - for example as when
one says "the data is stored in memory". For you, a clearer way to
ask the intended question is then : What do we call this methodology
for representing our data?

The fact that the code was written in C not C++ doesn't seem important
- particularly given the graphic element abstraction. I personally
don't mind calling it "OO", particularly in the context of making a
comparison to the relational paradigm for representing the CAD drawing.

I hope this example illustrates my choice of terminology.


Again, you lock onto your particular interpretation of what I say (ie
"image processing domain")

Which "particular interpretation" ? Want to read in a dictionnary for
the word "processing" ?

(snip whiny-whiny)


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.

1/ Did I say it wouldn't work ?
2/ Where do you think your OODBMS stored the data anyway ? On a clay
tablet ?

I didn't even express disagreement in your preference to use a file
system and you still take offence!


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.

yes, possibly. This is related to your program's needs, not to OO vs RM.


(snip)
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.

You mean "I have a proposal for when to choose between OO and RDB" ? As
I already tried to explain, this is pure non-sens. The only sensible
thing you came with by now is that for one of your programs, choosing an
OODBMS felt more appropriate than choosing a RDBMS.

I would rather you not take offence or be so angry!

Cheers,
David Barrett-Lennard

.

Relevant Pages

  • 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)
  • Re: Relational database & OO
    ... Actually a program is all about storing, because you store ... An ORM framework sitting on top of an RDBMS ... persistence, you're talking about the means by which data is moved to a ... example of inappropriately re-implementing the data management features ...
    (comp.object)
  • Re: Relational database & OO
    ... pretty sure I've read plenty of talk about 'storing' data in a stack, ... Actually a program is all about storing, because you store ... 'persistence' evokes very different concepts in my mind and in yours, ... Everybody with a solid background using RDBMS knows that a RDBMS is ...
    (comp.object)
  • 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 ... You don't 'store' GUIs nor image processing. ...
    (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)