Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Sun, 04 Jun 2006 15:46:16 +0200
> mAsterdam wrote:
>> Sasa wrote:
>>> mAsterdam wrote:
>> Do you agree that >> x A DBMS is not storage.
Except when a database runs out of storage,
I think the issues of a DBMS seen as storage are
completely irrelevant to any user or application
interacting with it.
Actually this disagreement makes the rest of the
Actually this disagreement makes the rest of the conversaton chit-chat.
>> x Sharing data is not a consequence of persistence.
> ... 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.
>> ... >>>> 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.
> 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. >> >> 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. >> ...
> 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 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.
>> 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