| 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: >>> >>>> 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?
>>> 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 didn't say you said it :-) I used the statement as a drammatical entrance to the subject :-)
> Aside: You snipped away your question.
> I repaired the damage, but I do not enjoy doing that.
> Please don't oversnip.
Sorry, to my mind your answer was standalone and I didn't see the substantial need for the original question to be repeated.
>> but is this simply not the consequence of persistance?
>> I mean - flat files offer this facility as well.
The same holds for RDBMS. 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.
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).
>> 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 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.
Not really - the OO code which uses database is not aware of the specific implementation.
>> When analysing or debugging the data I most certainly use the query >> editor and write ad hoc queries to find out what interests me.
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.
>> 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".
If I regard entire DBMS as a persistence than all of its features (querying, security, reliability etc.) are obviously persistence related.
>
>>>> 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? >> >> >> >> 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.
Most businesses want to have their data at their own network, so the DBMS existence and supporting staff is usually inherently there.
Other than that, the features listed above should support the cause. But ...
>> The data is hence in the database only because it must persist.
... it depends on the case (the specific app being developed).
>> 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.
Yes, where we were the customers (in your dictionary). The end user 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).
>> 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.
Now I don't understand this statement. In this passage I was pointing out the duplication problem.
>> To summarize - there are two problems: >> 1. Complex ifological sequential logic
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.
>> 2. Code reuse which supports variations on appropriate places
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?
>> 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.
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?
>> Disclaimer: I can agree that the example just presented was simply bad >> implementation (it most certainly was).
That's what I want to hear. How do you envision the role of DBMS?
>>>> 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?
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?
The same question for RDBMS.
How do you divide responsibilities between two if they are used in the
same system?
>> If yes, of what parts (with respect to languages) should a typicall >> application consist?
Thanks for the tip, will certainly investigate.
>> Do you apply such approaches in your apps and how does it works for you?
Sasa Received on Sat Jun 03 2006 - 05:05:08 CDT
 |
 |