Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 03 Jun 2006 16:41:48 +0200
Message-ID: <44819f46$0$31650$e4fe514c@news.xs4all.nl>


Sasa:
> mAsterdam:

>> Sasa:
>>> mAsterdam:
>>>> Sasa:
>>>>> Marshall:
>>>>>> 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?

...
>>>> 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. 
>>
>>> ... is this simply not the consequence of persistance?

I'll ask again: How is the sharing of data the consequence of persistence?

>>> 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.

>
> The same holds for RDBMS.

At the abstraction level of design - no, the same does not hold.

Only at a low level of communication the application is sending or retrieving bytes to and from the DBMS; not at the level you are designing. At that level data is sent and received, or, if you are one of the people who define data as meaningless and information as meaningful, information is sent and received.

(/I/BMS anyone?)

> If it's not available via network or at the
> client's site it is unavailable.
> The client still must be instructed in
> the structure of the database.

Two parties communicating must have some common reference. Antropomorfically (as in 'must be instructed'): The client does not need to know anything about how the data is stored. The database does not need to know anything about how the data is rendered.
The application only needs a partial information structure of what is in the database, the database only needs a partial information structure of what is in the application. Only the information in their interactions needs to be supported by a common reference.

> Granted though, RDBMS are standard whereas flat files are proprietary so
> it is much easier to reverse engineer a database (if no manual is
> available).

Both the structure of the files or the
(logical part of) the schema
are part of the software design.

>>> Now, I am very well aware that RDBMSes are much more powerful than >>> flat files,
...
> Normalization, querying, security, integrity, reliability, concurency,
> atomicity etc. come to mind

But not /sharing/ ?

>>> 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?

>
> Not really - the OO code which uses database is not aware of the
> specific implementation.

Along these antropmorfic lines:

For an object to be persistent, regardless of the specific implementation, it has to somehow be able to provide and package all information, necessary for a subsequent incarnation.
At some point in development this ability has to be designed. When this has been taken care of one can choose to be agnostic about that as long as the common reference does not change. In the case of a filesystem the common reference is bytes.

>>> 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?

>
> What kind of app would it be i.e. for what kind of users? I consider SQL
> statements other than simplest ones to be fairly inappropriate for the
> non programmer user.

How do you provide the users with ad hoc query facilities?

>>> 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.
>>>
>>> Well to me, most of these other features are rather "persistence 
>>> related".
>>
>> Sharing data can be persistence related.
>> Naked persistence only gives you very clumsy ways of sharing.
>>
>> Please give some specifics regarding "these other features".

>
> If I regard entire DBMS as a persistence than all of its features
> (querying, security, reliability etc.) are obviously persistence related.

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).

>>>>> 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.  
>>>>
>>>> "no client code in DBMS" - could you give an example of what you'ld 
>>>> consider typical client code?
>>>
>>> As can be seen from my other posts, I write my domain logic (the core 
>>> business data and behavior) in OO and use RDBMS for persistence. 
>>
>> 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)?

>
> Most businesses want to have their data at their own network, so the
> DBMS existence and supporting staff is usually inherently there.

I'll summarize that as:
The additional investment is not visible/out of pocket.

> Other than that, the features listed above should support the cause.

Those would be: Normalization, querying, security, integrity, reliability, concurrency, and atomicity, right?

 > But ...
>

>>> The data is hence in the database only because it must persist. 
>>
>> A secure, backed-up filesytem will do nicely for persistence only.

>
> ... it depends on the case (the specific app being developed).

Could you give an example where a DBMS purely for persistence is /not/ gross overkill?

I apologize for being persistent about this - maybe you have the impression that you already answered it, but I can't make anything out it, so I'll just repeat the question:

"no client code in DBMS" - could you give an example of what you'ld consider typical client code?

>>> 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?

>
>
> Yes, where we were the customers (in your dictionary). The end user

:-) At c.d.t. I /do/ maintain a glossary, and 'client' is not one of the entries because we never had a real misunderstanding about the term. I still don't think it is necessary to enter it.

> would receive entire app (client code and database). There were multiple
> end users. So I think you misunderstood me a little (or I didn't
> describe it accurately).

Let's see (below).

>>> 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.

>
> Now I don't understand this statement. In this passage I was pointing
> out the duplication problem.

Maybe an additional question helps:
You did have some server-side, customer specific code (some stored procedures).
Did you have n-plication at the client-side?

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

>
> Caculating algorithm consists of many sequential steps, after almost any
> step if else if ... branch occurs, as the algorithm (as defined by end
> users in their financial domain) is complex per se.
>
>> BTW: Where was this in what you are summarizing?

>
> In the "lot of verbose, bulky IF THEN ELSE blocks" but very poorly
> elaborated. Hope this previous paragraph sheds some better light.

It does, thank you.
I see what you mean - not to be miscontrued as agreement :-)

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.

>>> 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?

>
> This statement again I don't understand. The problem I was referring to
> is that end users use the same app (visually) with same business
> entities, and almost the same business rules (in this case financial
> calculations).
> How do you promote maximal reuse via DBMS?

Maximal reuse is not a goal in itself.
By viewing the DBMS as a persistence
engine you condemn yourself to having
lots of redundant code. Some of it redundant because it is elsewhere, but because it isn't at all necessary. A lot of business rules (in theory; some say all, also in practise, I don't know about that) can be implemented as constraints and data-derivations.

>>> 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.

>
> What do you mean? There is a choice as there are multiple paradigms,
> languages, technologies and tools available to solve the problem. You
> have to select which ones will you use and distribute the responsibility
> to each one selected. Is that not the act of choosing? Given the fact
> that there are multiple possibilities isn't one faced with a choice?

Let's step out of the box: Given that there are so many different musical instruments isn't one faced with a choice? Sure - at the time one chooses an instrument to play. The drummer doesn't have to know about ii-V-I chord sequences, the piano player doesn't need to know about paradiddles. At time of making music, though, it is just a matter of orchestration, listening very carefully and playing together.

>>> Disclaimer: I can agree that the example just presented was simply 
>>> bad implementation (it most certainly was).
>>
>> Let's talk about good implementations :-)

>
>
> That's what I want to hear. How do you envision the role of DBMS?

For that to be discussed we need more common ground. Sorry if this sounds arrogant, but at this point I really have to put a lot of effort into making a lot of huge moves around (what I see as, but might not be) basic misconceptions.

>>>>> 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.
>>>
>>> Well I'm obviously on the OO side, but would like to hear some 
>>> specifics from the cdt guys, to expand my horizons, learn something 
>>> new, shift my way of thinking etc.
>>>
>>> Do you think OOLs are inferior to RDBMSes in all aspects,
>>> and if so are they redundant? 
>>
>> No I don't.

>
>
> Great (would be also great if you had answered with a yes)!
> What are then in you view strengths of OO, when is it appropriate and
> when not?

How to organise your code?

OO is strongest when it comes to partitioning large software projects. OO gives a nice set of metaphors, to make it easy to achieve modularity (like in Myers-Constantine etc..SASD, cohesion, coupling) in a relatively easy, but more importantly, commonly understood way.

> The same question for RDBMS.

How to organise your data?

> How do you divide responsibilities between two if they are used in the
> same system?

The more important, and nowadays often neglected question is: what do they /need to/ have in common?

>>> 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.

>
>
> Thanks for the tip, will certainly investigate.
>
>>> 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 - 09:41:48 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US