Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Sat, 03 Jun 2006 23:15:28 +0200
Message-ID: <4481fb94$0$31651$e4fe514c_at_news.xs4all.nl>
Sasa wrote:
> mAsterdam wrote:
>
> [snip]
>
> I've purposely avoided continuing the first part of discussion, as it
> seems to me it doesn't lead to something essential or constructive
> anymore and this posts are getting fairly long.
It leaves the most basic issues unresolved.
Do you agree that
x A DBMS is not storage.
x Sharing data is not a consequence of persistence.
x Interpretation problems with sharing data
via bytes in files do not hold for RDBMS. x the (logical part of) the schema is
part of the software design.
> ( Update: it took me almost an hour to write the post :-( this is
> getting to be exhausting and time consuming)
I sympathize with that - and the posts are getting way to long, agreed.
> If you think I've avoided something relevant, feel free to introduce it
> back to the discussion.
Leaving out foundations leaves nothing much
to build on, does it.
I'll call sir snip-a-lot.
[snip]
> Do I understand correctly that "common reference" signifies that what
> two system have in common?
Yes.
> Only if a object is stored as a pure byte after byte image?
> If you write your isolated mini persistence API with general services,
> and then a layer on top of it which knows how to persist instances of
> specific classes using that API, the common reference is entirely
> represented in the layer.
...
>> How do you provide the users with ad hoc query facilities?
>
>
> Where I had to do this, the 'ad hoc' query feature amounted to
> combinations of simple filters (which would map to the WHERE part of the
> query). When multiple filters were used in most cases only logical and
> was supported. The set of attributes available in filtering was
> predefined. There was no relational filtering (e.g. give me all orders
> for customers which satisfy...)
> That was more than enough for the end users.
> Having these prerequisites in mind, the internal representation of the
> filter would be made in dedicated classes, representation of its
> combination would be the collection of instances of such classes, with
> the isolation layer translating this into implementation specific (e.g.
> parts of the select statement).
> This then makes the user independent of the specific on how the data is
> searched.
...
>> Queries give user meaningful data (or information if you >> care to define etc.) as results, not objects. >> >> How then is querying data related to objects, or more specifically >> object-persistence? (m.m. security, reliability).
>
>
> To expand my statement. Since I use the DBMS primary for persistence
> services, then
> 1. Querying the DBMS means querying the persisted data.
> 2. Security features of the DBMS relate to the persisted data.
> 3. Reliability applies to the persisted data.
>
> What is in my database is then the data, and there are no notion of
> objects there.
>> Could you give an example where a DBMS purely for persistence >> is /not/ gross overkill?
>
> Banking loan application serving couple of hundred clients
> simultaneously, processing couple of hundred thousands pieces of
> information (client, loans etc.)
> The extreme counter example could be simple address book tuned for only
> couple of dozens of entries, each entry containing only few attributes
> (e.g. name, last name, address and phone) which is designed to be used
> as a single user desktop application. I could imagine using XML for such
> app.
You surely mean this as an example where a DBMS purely for persistence
/would/ be gross overkill, right?
Aside: Even XML is seriously bloated for this app.
A simple boulder will do nicely:
http://stein.cshl.org/software/boulder/docs/Boulder.html
> I suspect this will not shed the light, though. It would be more
> interesting to see the cases where it is not so clear whether to use
> simple files or relational database as a storage.
>
> Could you provide your own examples?
...
> What is the client in your language?
Klant (Dutch ;-)
> I use the term for everything which is being served by something else.
> E.g. if function a uses function b then a is the client and b is the
> server. The end user is the client of the app etc.
>
> This is probably to broad of a usage, sometimes my coworkers don't
> understand me (especially when I use server for something that doesn't
> represent web or database server).
...
>> I will not go into the sequential/non sequential nature >> of infological complexities here. This post is already way >> to long. Maybe later. Maybe in another thread.
>
> As you please. I'm sorry though, as this is in my view one of the more
> important reasons why I prefer OOL to RDBMS for domain logic. I would be
> very glad to hear some oppinion from the "opposite camp" (don't take
> this term to seriously).
Well, I'm not the only one reading this - but I'm sure you would have to give something more to go on. Received on Sat Jun 03 2006 - 23:15:28 CEST