Re: OO versus RDB
Date: Thu, 29 Jun 2006 20:51:37 +0200
Message-ID: <44a42097$0$31656$e4fe514c_at_news.xs4all.nl>
H. S. Lahman wrote:
> Responding to mAsterdam...
[snip persistence]
>>>>>>> ... No, it is about solving problems (OO) >>>>>>> vs. persisting data (data management). >>>>>> >>>>>> What do you mean with "solving problems (OO)" - >>>>>> are they synonyms to you? >>>>> >>>>> 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. 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
- Orthogonal persistence in the object school to dissmiss all problems of data sharing as 'implementation issues'.
- Stretching *type* in the relational school to dismiss 'class' as a valid concept and still have it.
- (Most unfortunate:) stretching *meaning* to include *use*.
>> 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.
>>> 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. >>> >>> The point is that data management and problem solving are quite >>> 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.
[snip]
>>> I really don't know why this notion of separation of concerns is such >>> a novelty. >> >> Your assumption is wrong.
>
> What assumption?
[snip]
>>>>>> 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.
-- "The person who says it cannot be done should not interrupt the person doing it." Chinese Proverb.Received on Thu Jun 29 2006 - 20:51:37 CEST