Re: OO versus RDB
Date: Sat, 01 Jul 2006 17:08:57 GMT
Message-ID: <J_xpg.22221$US2.19941_at_trndny03>
>>>>>> No. OO is one form of problem solving just as a RDB-based DBMS is
>>>>>> one form of data management.
>>>>>
>>>>>
>>>>> "form of"? "problem solving" (in general instead of
>>>>> some category of problems) - I all sounds huge, but
>>>>> I fail to see what you mean by it.
>>>>> I'll try something I could understand using similar words:
>>>>>
>>>>> OO is one set of solutions for one problem,
>>>>> how to organize code: 'Sesame, open!' instead of 'Open Sesame!'.
>>>>
>>>>
>>>> I prefer: OO is a paradigm for solving problems on a computer.
>>>
>>>
>>> Big words ('paradigm', 'solving problems') only
>>> confuse the issues.
>> >> >> They have well-established definitions (e.g., a paradigm is a >> conceptual model) so they enhance communication. > > > http://en.wikipedia.org/wiki/Paradigm supports you, > but also gives: > 'Some language purists feel that among "business philosophers" and > advocates of any type of change whatsoever, the term paradigm is widely > abused and in that context bears no meaning whatsoever.' > > I don't think I am a language purist, but I share that opinion. > Now if we would be discussing paradigmatic behaviour: > Why some OO adepts refuse to discuss other problem-solving > at all, or why some RM adepts refuse to admit that order > may have meaning, I'd accept paradigm as a useful concept.
Well, I'm not one of those OO adepts. CRUD/USER processing is still an enormous part of IT software and the RM-based RAD IDEs have that pretty well in hand. Similarly, functional programming represents the best approach I know of to algorithmic processing when requirements are nonvolatile. There are a number of other, more specific problem spaces where OO techniques are not the best choice.
> See also: > > http://groups.google.nl/group/comp.databases.theory/browse_frm/thread/3e9cff0677ec34c1/03b78f4ae032a74e?lnk=st&q=(paradigmatic)+group%3Acomp.databases.theory+author%3AmAsterdam&rnum=4&hl=nl#03b78f4ae032a74e > > --------------------------------------------------------- > ...I suspect a lot of the miscommunication > between people from different schools of thought is > due to stretching the meaning of school-internal > words when confronted with problematic issues, > partly to avoid the use of *their* concepts, > partly to cover up paradigmatic blind spots. > Not unlike the not-invented-here syndrome. > > Three examples would be > > 1. Orthogonal persistence in the object school to > dissmiss all problems of data sharing as 'implementation issues'. > > 2. Stretching *type* in the relational school to dismiss 'class' > as a valid concept and still have it.>
> 3. (Most unfortunate:) stretching *meaning* to include *use*.
> ---------------------------------------------------------
This is all quite OT and I really don't want to go down this philosophical road.
>
>>> What problem does one attempt to solve with
>>> OO but the organization of code?
>> >> >> That's true, > > > Good. > >> but so abstract it is irrelevant for this context. > > > If you mean this (our) discussion with "this context" > I veto that. > >> General Ledger. Inventory control. Printer device driver. ad >> infinitum. Every computer application solves a specific problem for >> some customer. > > > None of these is OO specific.
Of course not. Nothing in this subthread (since my entry) has anything to do with OO.
This list was in response to your questioning what "problem solving" is. These are examples of the appropriate level of abstraction for defining problems for individual software applications.
>>>>> The point is that data management and problem solving are quite
>>>> However, my objection above was that it is not synonymous with
>>>> problem solving because problems can be solved on a computer with
>>>> different paradigms than OO.
>>>>
>>>>> Data management is done by people.
>>>>> A DBMS is part of the toolkit.
>>>>
>>>>
>>>> Fine. Just as problems are solved by people while editors,
>>>> compilers, code generators, etc. are tools.
>>>>
>>>> different concerns and activities.
>>>
>>>
>>> ?? Data management does not solve problems? Are you sure?
>> >> >> It solves problems that are restricted to that realm, such as ensuring >> data integrity. In a broad sense it can include notions like data >> warehousing but in this context I see it as being about the services >> that a DBMS provides. It generally does not involve solving specific >> business problems. > > > Why do you only state this for DBMS , it goes mm. for OO as well. > I won't bother.
I don't follow this at all. OO is one of many techniques for constructing software applications. Applications are constructed to solve specific business problems. The issue is what applications do relative to what DBMSes do, not what OO does.
>>>>>>> I don't use paradigms for storage.
>>>>>>> I don't use a dbms for storage.
>>>>>>
>>>>>>
>>>>>> Codd's relational data model as implemented in RDBs is not a data
>>>>>> storage paradigm?
>>>>>
>>>>>
>>>>> Indeed it is not.
>>>>
>>>>
>>>> Wow. I give up. This disagreement is so profound I don't even know
>>>> how to begin to respond.
>>>
>>>
>>> What is there to disagree on?
>>>
>>> Assume Bill wants storage.
>>> Say he goes to the shop and buys a DBMS.
>>> Now Bill still needs to buy storage!?
>>> What did he buy the DBMS for?
>> >> >> I don't understand this. You seem to be equating data storage to >> hardware. The hardware platform is not relevant. > > > Your assumption here is also wrong.
OK, then I don't understand what your point is.
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
Received on Sat Jul 01 2006 - 19:08:57 CEST