| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
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.
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)
For what it's worth, I like discussing this with you - you are an empathic collaborator (as opposed to some others here in the thread). It would probably be better to talk this over a couple of beers, sadly I don't think it's feasible :-(
>
>> If you think I've avoided something relevant, feel free to introduce >> it back to the discussion.
Be my guest.
>> Do I understand correctly that "common reference" signifies that what >> two system have in common?
>> Only if a object is stored as a pure byte after byte image?
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.
The layer has a specific knowledge - how to persist OO representation into a specific persistence implementation. You design it taken specific needs into account.
> ...
>
>>> 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.
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.
Sorry, the user here meant the OOL code (here the client/user problem in my dictionary rises again :-( )
> ...
>
>>> 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.
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.
No. They should be designed semi-independently of the object persistence layer. The client (app(s)) dictates what it wants. The DBMS chooses how will it present it. The mapper, simply translates.
>>> 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 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.
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?
>
I think we agree more than it seems at a first glance, but it's still a notion I can't argument.
As already said, I regard sharing, concurrency and other benefits of RDBMS as a properties of specific persistence implementation (RDBMS in this case). Don't get me wrong, these are not irrelevant or secondary issues. However, they are a factor which affect choosing one or another implementation (I refer back to my previous two examples loan vs. simple address book).
>
>
>
> 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?
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).
And I understand them as well :-) It's just too difficult (to me) to be always concise and unambiguous.
> ...
>
>>> 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).
Such as?
Sasa Received on Sat Jun 03 2006 - 16:56:05 CDT
 |
 |