Re: Mixing OO and DB
Date: Thu, 03 Apr 2008 16:33:44 -0400
Message-ID: <m2ve2y1xw7.fsf_at_spe.com>
"Brian Selzer" <brian_at_selzer-software.com> writes:
> "Patrick May" <pjm_at_spe.com> wrote in message news:m27ifp5yyt.fsf_at_spe.com...
>> Ah, you may have identified the source of our miscommunication
>> here. We seem to be using "schema" differently, despite both of us
>> repeatedly attempting to clarify. Let's consider first an
>> application that doesn't use a relational database at all. This
>> application still has a schema in the sense of the data that it
>> uses internally to support the behaviors it exhibits. Are we in
>> agreement so far?
>
> I wouldn't put it that way, but I think I understand what you mean.
>
>> The implementation of this internal schema may change. For a
>> simple example, an array may be changed to a queue or a stack. In
>> this case the same data is being stored, but the behavior of the
>> data structure is different. A more complex example would be
>> changing a data member to a computation or vice versa. In these
>> scenarios, the application logic cannot be decoupled from the
>> schema representation.
>
> The potential information content, however, may not be different.
> Whether you use an array, or a queue, or a linked list, or a doubly
> linked list, or a binary tree, the information that populates those
> structures may be exactly the same information, regardless of how it
> is laid out.
I'm not positive that this is the case when considering only data, because some information may be either generated on demand (possibly with reference to components outside the scope of the system) or stored locally. Your equivalence also ignores the capabilities of the structures themselves. To a first approximation, though, I see your point.
>> Now consider the same application modified to use a relational
>> database. The application logic continues to use the same data
>> structures (stacks, queues, DAGs, etc.) and classes (we'll assume
>> it's an OO application, since this is comp.object) it was using
>> before. The implementation of the schema in the relational
>> database presents a particular interface. This interface is based
>> on relations. Some form of mapping must take place to convert the
>> data provided via that interface into the model used internally by
>> the application.
>
> This is where we diverge. The data is the same data whether it is
> represented as a relation or as a binary tree. It is not the data
> that is subject to conversion, but rather its representation. This
> may seem like splitting hairs, but the difference is in my opinion
> critical.
Split away. I agree that you've identified the difference. Imagine that, constructive conversation on Usenet. ;-)
> A schema specifies what is to be and can be recorded. It also
> suggests a structure, but that structure implies and is implied by a
> set of constraints that describes what the data is rather than how
> the data is laid out. That implied structure may differ
> significantly from what is optimal for a particular application,
> which is concerned less with what the data is than with how it can
> be used.
Our definitions of "schema" differ. I do include the structure as well as the data in my definition. That's not particularly important, however, because it's easy enough to rephrase the original point of contention. Would you agree that the data+structure used by an application can be decoupled from the data+structure exposed by a relational database?
Regards,
Patrick
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm_at_spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
Received on Thu Apr 03 2008 - 22:33:44 CEST