Re: Mixing OO and DB

"rpost" <rpost_at_pcwin518.campus.tue.nl> wrote in message news:79aef$47d28c45$839b4533$7035_at_news1.tudelft.nl...
> David Cressey wrote:
>
>>Before I move on, I have to give an opinion based on my own data-centric
>>world view. If you don't understand the data, then you don't know what
>>you're talking about. In short, I completely fail to grasp how one can
>>understand a system in terms of "behavior" without understanding the data
>>that the behavior affects. This is something that it's going to take me
>>years of lurking in comp.objects to grasp.
>
> I don't think so. Can we understand the differences between sets,
> multisets, ordered lists, queues and stacks just by
> "understanding the data"? Well, it depends on what you mean
> by "data", but my guess is that you'll agree that the differences
> between them are not so much in their data, in what information they
> store,
> but on how we can access and update this information; the laws that
> govern their interaction with the rest of the world. This is what the
> OO world calls "behaviour". Behaviour is what an object looks like
> from the outside. Data structure is what it looks like from the inside,
> its implementation. The behaviour of sets, or multisets, or lists,
> can be implemented with many different concrete data structures,
> and conversely, the same concrete data structure can be used
> in implementing many different abstract data types.
>
> Can we understand the behaviour of sets without having a
> concrete data structure in mind? Yes, definitely, we can
> write down set operations and the laws that govern them, e.g.
>
> operations:
>
> empty: Set<T>
> isempty: Set<T> -> Boolean
> in: T x Set<T> -> Boolean
> singleton: T -> Set<T>
> union: Set<T> x Set<T>
> intersection: Set<T> x Set<T> -> Set<T>
>
> laws:
>
> isempty(empty) = true
> for all e in T: in(e, empty)
> for all e in T: in(e, singleton(e))
> for all e in T: in(e, singleton(e))
> for all e in T, X,Y in Set<T>:
> in(e, X) or in(e, Y) <=> in(union(X,Y))
> for all e in T, X,Y in Set<T>:
> in(e, X) and in(e, Y) <=> in(intersection(X,Y))
> (etc.)
>
> It's not easy, and I'm no expert in it, but it can be done,
> and I don't think you'll call this "understanding the data".
> What is more, I'll claim that all of the "understanding data"
> that you claim to be capable of is essentially of this nature:
> even with a concrete data structure in mind to aid understanding
> and the implementation, the data structure doesn't really mean
> anything without specifying the operations that can be performed
> on it; and that meaning essentially consists of the laws that
> govern the behaviour of those operations as observable from the
> outside, and is thereby essentially independent of that concrete
> data structure.
>
>>And I suspect that, based on the
>>experience of people like Marshall Spight, that I'm going to conclude, at
>>the end of the day, that behavior is not the holy grail of computing.
>
> No, but it is absolutely crucial. We can't specify any data at all
> without thinking of how to interpret it; and interpretation means to
> think of operations and how they are supposed to behave.
>

No. Interpretation involves the assignment of meaning. It has little if anything to do with behavior or operations.

> In an RDBMS the focus is on data structures with "relational" behaviour,
> where the operations and their behaviour are fixed in the query language;
> this is a good fit for many of the data we need to work with in practice,
> but not for everything.
>
> [...]
>
>>In my original perspective, the single thing that ties together all the
>>applications and all the databases that collaborate by sharing data is
>>just
>>one thing: data.
>
> You might just as well say: behaviour. The way in which your systems
> represent and access their data is ultimately subordinate to how the
> systems are supposed to *behave*, their functionality.
>
>>If you understand the data, and you understand the
>>(observable) behavior of each of the applications and each of the
>>databases,
>>you can understand the system. Otherwise, you can't understand the
>>system.
>
> The opposite is even more true: no data can be understood without
> understanding what operations are used to obtain and apply the data.
> Here, I have some data for you:
>
> 1,129,960,000 March 8, 2008
> 303,569,100 March 5, 2008
> 231,627,000
> 186,315,468 March 1, 2008
> 162,652,500 February 29, 2008
> 158,665,000
> 148,093,000
> 141,933,955 March 1, 2008
> 127,790,000 December 1, 2007
> 106,535,000
>
> Completely useless, unless you understand which interactions
> with the real world these figures correspond to.
>
> So I think your suggestion that understanding is somehow tied to data,
> not to behaviour, is flat-out wrong. We do need to understand the
> operations on our data before we can understand the data. The reason
> relational database designers want to store data and not operations
> or laws of behaviour has little to do with where the information is,
> but it is purely due to the fact that in most RDBMS applications we can
> "factor out" the behaviour into the fixed set of common, parametrizable
> operations provided by the relational query language. (In reality, of
> course, this rarely suffices, because the query language is't powerful
> enough, and we have to kludge around with transactions and stored
> procedures to actually get the job done.)
>
> --
> Reinier Post
Received on Sun Mar 09 2008 - 04:36:19 CET