Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Sat, 03 Jun 2006 23:56:05 +0200
Message-ID: <e5t0h9$jrj$1_at_sunce.iskon.hr>
mAsterdam wrote:
> 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.
Sorry.
> Do you agree that
> x A DBMS is not storage.
No
> x Sharing data is not a consequence of persistence.
No
> x Interpretation problems with sharing data
> via bytes in files do not hold for RDBMS.
Partially, but really don't find it relevant.
> x the (logical part of) the schema is
> part of the software design.
Yes.
>> ( 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]
Be my guest.
>> 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?
>
>
> This should be irrelevant at the level of design, no?
> But you'ld have to design it if you go that way.
I lost you there, but somehow I don't think the subtopic is relevant.
>> 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.
>
>
> What is it that this layer must have in common with the database?
> IMO it is (a part of) the schema. How do you design it?
> ...
>
>>> 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.
>
>
> Short answer: you don't. Why so many words?
> I should have put 'How' in my question between parentheses.
Depends on what you really mean by ad hoc queries.
>> 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.
>
>
> On the contrary: It makes the user completely dependent on
> the few queries the application implementor designates
> important enough to build a wrapper for.
> ...
>
>>> 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.
>
>
> How can the data have any meaning by itself if it's just
> the storage for persistence you are querying? ISTM there
> is a serious hole in you design approach.
I don't see how not? It is the very specific data having its own nature. Where's the hole?
>> 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.
>
>
> And all tables, columns and constraints in your schema
> were designed and named by the object-persistence layer
> designers/programmers, for programs.
> ...
>>> 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.)
>
>
> I see two requirements /beyond/ (as opposed to /purely/)
> persistence here: data sharing and concurrency.
I see them more as a properties or features (albeit important ones) of persistence implementation.
>> 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?
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
Thanks for the tip :-)
>> 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?
>
>
> My position is that DBMS are not for persistence.
> You are asking me look for a counterexample.
> I tried. I can't.
>
> Your (and others') position is that you
> use DBMS for persistence.
>
> My take on that position is that people who say that
> have implicit requirements /beyond/ pure persistence.
> So I challenged you to come up with an example where a
> DBMS purely for persistence is /not/ gross overkill.
> Hopefully your or somebody else's answer will
> refute my position/take or expose some of the
> additional requirements.
>
> Right now we have sharing and concurrency.
>
> I tried. I can't. Can you?
>
> If you can't, will you accept that it is not (just)
> persistence what you are looking for in a DBMS?
I think we agree more than it seems at a first glance, but it's still a notion I can't argument.
>
>
>
> I'll skim the rest (constraints!) for now.
> Maybe later I'll go into it. It just to much for one post.
Acknowledged.
> ...
>
>> What is the client in your language?
>
>
> Klant (Dutch ;-)
Klijent (Croatian :-) ), but that was not what I asked you.
>> 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).
>
>
> Ok this one: I'll understand you if you use it this way. (But
> I also understand your coworkers sometimes forget that you use it this
> way).
> ...
>
>>> 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.
Such as?
Sasa Received on Sat Jun 03 2006 - 23:56:05 CEST