Re: OO versus RDB


Bruno Desthuilliers wrote:
David Barrett-Lennard a écrit :
Bruno Desthuilliers wrote:

(snip)

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,

What should I do with what you say ? Interpreting it has any other word
taken at random in a dictionnary ? Are you trying to express something
about computers and OO programming, or is this just some experiment in
surrealistic writing ?

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.

What else do you want to express ? main memory storage ? It boils down
to the same thing : bunches of bytes, mostly managed by the underlying
OS, with a language (not paradigm) specific layer above. Don't see any
major difference here. And still nothing relating to OO (or RM or whatever).

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.

Please read more carefully.

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

Bingo - main memory storage. Already adressed above.

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

Just like the distinction between technical and domain objects, this is
a moving target. But to put it short: what's getting executed is code,
what's being processed is data. In both cases, this really is only bits
in a computer...

(snip)

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").

Stop here. 'Data structure' == 'data' ?

Let's rephrase this :
"In C, we can allocate memory blocks and put some (more or less)
structured data in it."

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.

Are you going to teach me C and/or CS101 ?

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.

And ?

What do we call this methodology for "storing our data"?

file storage.


Whether the code used to write/read this is (more or less) procedural,
(more or less) OO or (more or less) functional is still irrelevant.

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?

A data structure. And I wouldn't call that a 'methodology'.

I know you don't. But I do. There is a big difference in representing
a CAD drawing using C style data structures, compared to representing
it using tables of records that represent relations.


Have another question ?

The fact that the code was written in C not C++ doesn't seem important

At least something sensible. Now s/C/Pascal/ and s/C++/Lisp/, then
s/Pascal/OCaml/ and s/Lisp/Perl, and you'll find it still isn't very
important. Wether you build it from nested lists, linked structs or
objects, a tree by any other name is a tree.

- particularly given the graphic element abstraction. I personally
don't mind calling it "OO",

Then you're confusing OO with structured datatypes. OO is usually
implemented with structured datatypes, OO can be used to model
structured datatypes, but OO - as a paradigm - is about objects and
messages. FWIW, using classes is not enough - nor is even required - to
do OO.

I'm not confused at all. I understand exactly what you say. Yes, it
seems if I had said "structured datatypes" all along you may not have
been confused! But remember that no one just stores information using
structured datatypes without also writing code that operates on that
state. So why do you need me to make the distinction?

If I write a CAD application using C/C++, an aspect of that task is to
model the state of a CAD drawing using data structures. Some may say
that OO is about behaviour not data structures, but that's just silly
because you can't have behaviour unless there is some state on which to
operate on. Note furthermore that OO doesn't hide the fact that there
are underlying data structures, just by calling them "objects" and
calling method calls "messages".

Therefore I still think it is quite reasonable to say "I used the OO
methodology to store the data". I don't care if you don't like it.
I'm more interested in the ideas than the terminology.


particularly in the context of making a
comparison to the relational paradigm for representing the CAD drawing.

FWIW, the relational algebra is somewhat bad when it comes to
heterogenous hierarchical structures, and AFAICT, CAD tools use a lot of
such structures - which may be a reason why RDBMS never really made it
in this domain. Just like markup languages are usually a better choice
for loosely structured documents.

Agreed. My original post provides (IMHO) an interesting perspective on
why this is the case.


I hope this example illustrates my choice of terminology.

Alas.

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

You mention having successfully used an OODBMS to store huge data. Fine.
FWIW, I did too. Now given the context, I question your reasons for
mentioning this fact.

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

Please don't assume anything about my emotional state.

Cheers,
David Barrett-Lennard

.

Relevant Pages

  • Re: Was this a bug
    ... that you didn't store in memory somewhere ... outside the array that you were trying to store in? ...
    (comp.lang.fortran)
  • Re: Exchange 2003 Private Store Corruption
    ... Once you've pulled the faulty RAM, create the new mailbox store and move ... then you can start working on the problem mailboxes. ... have DIMM's installed in pairs in this server? ... Online Diagnostic Utility says "Correctable Memory Threshold Exceeded" ...
    (microsoft.public.exchange.admin)
  • Re: OO versus RDB
    ... It boils down to the same thing: bunches of bytes, mostly managed by the underlying OS, with a language specific layer above. ... In C we can *store* data structures in memory (let's just call it ... I have stored multi-gigabyte multi-res images in an OODBMS and it works ...
    (comp.object)
  • Re: Can operant conditioning account for all learning?
    ... are not replaying the raw sensory data form that event. ... problems your high level abstractions didn't recognize. ... I would suggest it uses the same amount of memory more ... Most likely the brain doesn't store things in ...
    (comp.ai.philosophy)
  • mm/ hacks -- Generic memory store?
    ... I want to do a memory management hack for generic memory stores. ... "store" for excess memory before OOM. ... RAM swap ... store would be capable of providing compression or encryption. ...
    (Linux-Kernel)