Re: Mixing OO and DB

From: Dmitry A. Kazakov <mailbox_at_dmitry-kazakov.de>
Date: Mon, 11 Feb 2008 10:21:39 +0100
Message-ID: <86id9hkdr41t.1wn6h120tk1kl.dlg_at_40tude.net>


On Mon, 11 Feb 2008 01:52:48 +0100, mAsterdam wrote:

> Dmitry A. Kazakov wrote:

>> mAsterdam wrote:
>> 
>>> In your extension, you appear to map your slaves to data.
>>> Slaves behave, objects do. Data doesn't.
>> 
>> If data did not behave how would it be possible to use data?

>
> Being active is not, as your question presupposes,
> a prerequisite to being used.

No, I didn't meant that. Behavior is independent on who acts on whom. Consider it as a list of all things you could ever do with data.

>> [What is data, in your opinion? 

>
> Recorded facts.
>
> In the context of electronic dataprocessing
> it only makes sense to talk about data when the medium on
> which they are recorded is readable by some mechanism to
> achieve electronic representation, but that is not inherent
> to data.

True. Inherent is presence of some reading device.

But why is recording essential? It throws in many things which seem unrelated or constraining, such as time aspect and physical presence. Or to put it otherwise, can you consider unrecorded, not memorized data? May I translate data into a different representation and then erase the original record? Will data still be there?

>> On my side: data are values semantically
>> bound to some entities from the problem space. 

>
> The one recording the facts (or the designer of the datacapture)
> will have some entities in mind when recording/capturing the data.
> To make sure that the interpretation won't be far off, a
> description in terms of entities (from the problem space) helps.
>
> This does not garantee that the interpretation in terms of entities
> of formerly collected facts will stay the same.

Yes. That cannot be guaranteed.

> "semantically bound" suggests a formalism.
> Did you intend that? If so which one?

Actually it suggests absence of formalism. A formal system operates on data without any clue of the meaning of.

>> (The type of values describes the behavior of data.)]

>
> How? I don't understand what you are saying here -
> this may be a language thing, though.
> An example might clarify.

Consider the value 1. It has no behavior (and no use) so long you don't tell us its type. It you say that 1 is an integer, then its behavior will include "has negative inverse." If the type is Positive, then the behavior will be "no negative inverse", "can be squared in R" etc.

(Behavior does not presume anything like tiny cogwheels hidden inside 1. The cogwheels are rather big and all outside (:-))

>> If the ultimate goal is same, then managing the thing called data is mere
>> one possible thread of the process.

>
> That does not follow.
> Furthermore: after the process stops, the data remains.

Really? You wrote just above:

"it only makes sense to talk about data when the medium on which they are recorded is readable by some mechanism to achieve electronic representation, but that is not inherent to data."

Which is all true. So let you have a medium without a process that can read it, what did remain of data? It what sense do data remain? As a possibility to start a process by some other process which still runs? Consider it on the example with 1.

>>> Please describe the fence as seen from your side.
>> 
>> In short and technically, it is refusal to view tables as typed values.
>> 
>>> I see the same DB/DBMS conflation as Patrick made.
>>> I asked Patrick, and I'm asking you:
>>> Do you need that?
>> 
>> Yes, I do, especially when talking about a common ground.

>
> Patrick May considered his DB/DBMS conflation just sloppy,
> you need it.

No, his first, maybe unconscious, reaction was right. DB in interesting to us part is software, or else we should have been in sci.physics.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Received on Mon Feb 11 2008 - 10:21:39 CET

Original text of this message