Re: OO versus RDB
Date: Sun, 25 Jun 2006 19:08:33 GMT
Message-ID: <RaBng.2137$pu3.54048_at_ursa-nb00s0.nbnet.nb.ca>
H. S. Lahman wrote:
> Responding to mAsterdam...
>
>>>>>> In retrospect I think that what we were doing was trying to >>>>>> reach for (never to achieve) the level of data-independence >>>>>> which is now achievable with SQL-DBMS's even if they aren't up >>>>>> to RM-purist's standards. But, as I said, I will pay attention, >>>>>> maybe there are even more benefits to a layered approach of data. >>>>> >>>>> I would suggest even further isolation. >>>> >>>> Because this benefits ... what? >>> >>> Separation of concerns. >> >> Worthwhile. Which concerns? Code and data organization.
>
> No. Problem solutions vs. persistence.
You are an ignorant. The added isolation you mention only benefits 'problem solutions' when one chooses the needlessly complex computational model you chose in the first place. It's a straw man.
>>>>> The application solution doesn't care if the data is in an RDB, an >>>>> OODB, flat files, or clay tablets. >>>> >>>> Well, the user does care about his data. >>>> That's why he put them on clay tablets >>>> (or one of the other) to begin with. >>>> What type of user-beneficial application solution >>>> should not care about where the user's data is? >>> >>> The user doesn't care where the data is either. Nor does the user >>> have any direct access to the data; it is all through software. The >>> customer just decides What needs to be persisted, not how it is >>> persisted. Persistence is a Systems Engineering decision. >> >> This is about persisted objects (bits & bytes to the user), >> not about data as in meaningful, user visible data - the >> stuff data-management and databases are about. >> Now I know some would call that information instead of data, but that >> would mean we'd have to talk about >> information-bases and limping stuff like that.
Actually, if the information is represented suitably for machine processing, it is data regardless whether a machine processes it. The fact that all data is information does not make it any less data.
> No, it is about solving problems (OO) vs. persisting data (data
> management).
You are an ignorant. Since OO introduces the problems in the first place, one really has no need to solve them in the first place.
>>>>> So one should hide the SQL as well. >>>> >>>> As soon as we have a better embeddable >>>> abstraction, yes. Please provide an url. >>> >>> What if you decide an OODB would be better?
If, by OODB, you mean a network model dbms, one would have to be a complete embecile to decide it is better.
>> If a problem at hand doesn't need >> data-management, I might recommend one if >> say a software vendor has build a >> niche-solution needing it.
In other words, if one doesn't need to manage data, one has no need for data management. The real question is: What value are tautologies and circular reasoning to anyone but a moron?
> The point is that the application problem solution does not care how the
> data is stored.
That meaningless anthropomorphism might even approach relevance except for the concern for cost, the concern for correctness, the concern for performance, the concern for security, the concern for concurrency, the concern for relevance etc.
Nor should it be affected by any changes to the data
> storage that do not effect its semantics. In half a century in this
> business I've observed the introduction of five major paradigms for
> persistence. I would not bet against yet another appearing.
There goes that meaningless buzzword 'paradigm' again. I would not bet against another logical data model appearing any more than I would bet against some genius eventually inventing a better formalism than predicate calculus.
>>> As such, it should be hidden from the rest of the application that >>> doesn't care what flavor of persistence is used. >> >> In the case of using SQL as interface to users data: >> make sure that only that part of our code which >> processes some specific data mentions only that >> part of the schema which is relevant to it.
>
> Better yet, encapsulate it so that none of the problem solution code
> mentions it.
Or better yet, use logical independence to separate the concern for correctness from the concern for adaptability much more effectively and at a much higher level. But that wouldn't give snake-oil salesmen such as yourself nearly the same opportunity to invent a career out of meaningless gibberish.
>> I don't see how an extra layer dealing >> with (especially when specific data) could help >> - ISTM it only blurs the separation of concerns.
>
> Encapsulation and isolation. When the schemas and/or access paradigms
> change one does not have to touch the problem solution in any way.
More meaningless gibberish and buzzwords. Logical independence and application views already solve the problem OO reinvents.
So
> one can be confident that the problem solution still works.
One can be just as confident of a solution through intelligence, knowledge and mathematics as through ignorance and incompetence. It might require a little more work, but it's a lot more valid.
All one
> needs to validate is that the layer or subsystem interface still
> provides the same data in response to requests from the problem solution.
Validation is for parking downtown. I would prefer to prove the correctness of my solutions.
>>> One provides that encapsulation with a subsystem interface that is >>> tailored to the problem solution's needs.
Well, if one was stupid enough to create that problem in the first place.
Ideally one employs a pure
>>> message interface: {message ID, data packet}.
Ideally, one avoids the whole problem in the first place. But, I suppose you wouldn't have as much opportunity for selling nonsense that way.
It is then the
>>> persistence access subsystem's job to map that message into a SQL
>>> query or whatever else is needed.
Again, only if one was stupid enough to do things that way in the first place.
>>>>> In so doing one can often provide reusable storage access across >>>>> applications where one only needs to provide a subsystem interface >>>>> and identity mapping to access the data for a particular context. >>>>> SQL is particularly suited to this because one is just >>>>> concatenating identity strings. >>>> >>>> SQL DBMS mostly use files in file systems for storage. >>>> Why place SQL DBMS in between if you are just looking for storage? >>> >>> Because outside the realm of CRUD/USER the problem solution should >>> not depend upon the persistence mechanisms. >> >> No - I'll rephrase: why not use storage systems for storage? >> Why use SQL as a go-between at all?
>
> I don't care what storage paradigm is used or what access mechanisms one
> uses to access the data store.
Here you prove beyond any possible doubt that you are just ignorant and stupid. One would use an SQL dbms for a variety of reasons all related to very powerful means to achieve fundamental data management goals: security, integrity, concurrency, recovery, well-defined logical units of work, physical independence, logical independence, an extremely powerful set-level manipulation language, etc.
If you are too stupid to recognize any of those reasons, there is no wonder you make such idiotic statements with such frequency and predictability.
The point is that, whatever they are,
> they should be isolated from the problem solution so that they are
> completely transparent to the problem solution.
If you are too stupid to realize that all of those reasons are solutions, I am amazed you can dress yourself.
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> hsl_at_pathfindermda.com
> Pathfinder Solutions -- Put MDA to Work
> http://www.pathfindermda.com
> blog: http://pathfinderpeople.blogs.com/hslahman
> Pathfinder is hiring:
> http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH
Contact the above if you have a use for self-aggrandizing ignorant
snake-oil salesmen. I don't have any such use. Plonk.
Received on Sun Jun 25 2006 - 21:08:33 CEST