Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

>> Sasa wrote:
>> 
>>> Marshall wrote:
>>>
>>>> There is a fundamental, foundational concept to grasp here,
>>>> that is easily obscured by the excessive verbiage. But
>>>> unless you get this foundational point, you won't be able
>>>> to follow the arguments of the c.d.t. people at all. So I'll
>>>> simply present it in isolation.
>>>>
>>>>   A DBMS is not "storage." A DBMS is a system that manages
>>>>   data, where "manages" describes a whole host of high level
>>>>   facilities.
>>>
>>> So can you list some short but specific keypoints - what are these facilities?

mAsterdam replied:

>> One key facility would be the /sharing/ of data;
>> between instances of applications (persistence can be
>> viewed as a specific case of this: sharing between
>> subsequent incarnations/runs), but also between different
>> applications. 

> No one ever disputed that (well at least, I didn't dispute it),

I did not say or think that you /did/ dispute that.

Aside: You snipped away your question.
I repaired the damage, but I do not enjoy doing that. Please don't oversnip.

> but is this simply not the consequence of persistance?

How?

> I mean - flat files offer this facility as well.

You can share your data by putting bytes into files and send the file to the ones you want to share the data with (or put the file on a networked filesystem). Don't forget to instruct the other parties how to interpret the bytes in the file.

> Now, I am very well aware that RDBMSes are much more powerful than flat
> files,

Agreed. Your other statements makes me wonder, though: In what sense are they more powerful in your view?

> but in my current view - I regard both primarily as a persistence
> from my OO biased perspective. Why do I usually choose RDBMS over flat
> file? Because of this great features you and other have mentioned.
> Do I treat then RDBMS as a flat file? Most certainly not - I have a
> isolation layer which decouples my OO code from my RDBMS code. Behind
> that layer I can fully leverage the power of RDBMS.

That seems like a sensible design heuristic for many applications.

 > From the client side I'm not aware of RDBMS existence.

If you would have said "The application user does not for day-to-day use of the application need to be aware of the existence of the DBMS" I could agree. Is that what you meant?

> When analysing or debugging the data I most certainly use the query
> editor and write ad hoc queries to find out what interests me.

Do you also relax the isolation requirement for user ad hoc queries?

> I worked on a legacy app which used proprietary flat files for
> persistence. It was a nightmare when I had to analyze what's in there.
>
> So no, I don't think I'm fully underestimating the power of the dark
> side :-) Sorry just couldn't resist - no harm meant there, I meant the
> power of the RDBMSes. I am open to the possibility that RDBMSes can be
> ever more used than I am currently using them, and are much more
> appropriate for some stuff I currently do in OO. But to accept this
> notion I would need more specific details on your preferred approaches.
>

>> Why not? Simply serializing/deserializing all objects
>> (like smalltalk did - the "system image")
>> to a file on secure media gives you perfect persistence.
>> That you want more shows that you already are
>> aware of some desiderata beyond just that.

Sharing data can be persistence related. Naked persistence only gives you very clumsy ways of sharing.

Please give some specifics regarding "these other features".

>>> Given the fact the DBMS can serve more apps (but actually even one 
>>> can mean trouble if SQL code is spread around the app code), and 
>>> given the fact that one app might want to switch DBMSes I think it 
>>> would be smart to decouple both as much as possible, which to me 
>>> means no client code in DBMS, and very localized DBMS specific 
>>> statements in client code. Now 
>>
>>
>> "no client code in DBMS" - could you give an example of what you'ld 
>> consider typical client code?

Don't. If persistence is all you need, a DBMS is terrible overkill. How do you justify the additional investment (not talking licenses, but mainly the creation and maintenance of the staff's DBMS skills)?

> The data is hence in the database only because it must persist.

A secure, backed-up filesytem will do nicely for persistence only.

> Moving the behavior to the DBMS would mean moving
> client code (the non DBMS code which somehow directly
> or indirectly uses the database) to the database.
>
> I was working on a financial application once, where a lot of such logic
> was implemented in the SQL database. There was number of large stored
> procedures which performed complex financial calculations. The code
> looked horribly - with lot of verbose, bulky IF THEN ELSE blocks, etc.
> it reminded me more of my BASIC days than of the professional code.
>
> In addition, the app was being distributed to different clients. Between
> any two clients some subset of the calculation algorithm varied to some
> degree, with most of the logic being the same.
>
> This was being resolve by simply switching the stored procedures code -
> for each client we had the SPs scripted. The structure being used
> (tables) was the same.

So, you had some server-side, customer specific code (I say customer here to disambiguate from client as in client/server architecture). You did provide your customer with the schema DDL in the distribution package, didn't you?

> So if we wanted to work on an app for another clients, we would execute
> appropriate scripts which would then regenerate SPs and then we would
> have the appropriate code. Needless to say, there was fair amount of
> duplication (or rather n-plication) with slight variations in some places.

Customer specific issues at the client-side have to be resolved as well. I don't see a fundamental difference.

> To summarize - there are two problems:
> 1. Complex ifological sequential logic

Please elaborate.
BTW: Where was this in what you are summarizing?

> 2. Code reuse which supports variations on appropriate places

There may be customer specific code on both client and server. You either prevent that or you don't. How does this relate to persistence?

> Now, I have fairly good idea how to resolve these in OO, but have no
> idea how do you deal with such issues in DBMSes. Simply, when it comes
> down to the behavioral, sequential code, and as far as I know it has to
> come down to it sooner or later, I regard OO as a better choice.

IMO There is no choice here.
There is just appropriateness of metaphors and discipline. Pretending there is a choice here culminates in a counterproductive us vs. them attitude.

> Disclaimer: I can agree that the example just presented was simply bad
> implementation (it most certainly was).

Let's talk about good implementations :-)

>>> I'm interested with what part you DBMS guys (no irony, or offense 
>>> meant) disagree and how do you envision it?
>>
>>
>> I'm not fond of the us vs. them approach - but I am a c.d.t. regular.

No I don't.

> If yes, of what parts (with respect to languages) should
> a typicall application consist?

That is to big a question to answer.
IBM abandonded the SAA (standard application architecture, early 90's) when they found out. You are not the first to ask.

For the non-sequential infological approach I like ORM, for c.o.: that is Object Role Modeling, http://www.orm.net/ not Object-Relational-Mapping which IMO is a non-issue, stemming from the OO-side of the destructive us vs. them attitudes. If you care to investigate: don't be confused by the graphics.

> Do you apply such approaches in your
> apps and how does it works for you?

Yes. Not everywhere (appropriateness!). Received on Sat Jun 03 2006 - 11:32:42 CEST