Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Sun, 04 Jun 2006 15:46:16 +0200
Message-ID: <4482e39f$0$31650$e4fe514c_at_news.xs4all.nl>
Sasa wrote:
> mAsterdam wrote:
>> Sasa wrote:
>>> mAsterdam wrote:
[snip]
>> Do you agree that >> x A DBMS is not storage.
> No
>> x Sharing data is not a consequence of persistence.
> No
Please try to clearly explain how it /is/, then.
> ... 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 :-(
It's not that far :-)
>>> ... 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?
>
>
> The layer has a specific knowledge - how to persist OO representation
> into a specific persistence implementation. You design it taken specific
> needs into account.
What /is/ it (beyond the part of schema the application needs)?
>> ... >>>> 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.
Queries not defined at design time.
>>> 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.
>
> Sorry, the user here meant the OOL code (here the client/user problem in
> my dictionary rises again :-( )
Ok. Disambiguation: It makes the end-user completely dependent etc.
>> ... >>>> 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?
Organization of data, like organization of code, needs design.
>>> 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. >> ...
> 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.
"semi-independently" doesn't cut it.
>>>> 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.
Yes.
That is what makes it very hard to discuss any relevant design issues.
...
>> 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.
Ok for now.
> 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).
>> ... >>> What is the client in your language? >> >> Klant (Dutch ;-)
>
> Klijent (Croatian :-) ), but that was not what I asked you.
> ... It's just too difficult (to me) to be
> always concise and unambiguous.
Sigh... yes, for me to.
>>> 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?
E.g. why infological complexities would be seqentail in nature. (BTW please start a new thread when you want to go into this.) Received on Sun Jun 04 2006 - 15:46:16 CEST