Re: OO versus RDB
From: H. S. Lahman <h.lahman_at_verizon.net>
Date: Tue, 04 Jul 2006 15:00:17 GMT
Message-ID: <5ovqg.2646$283.449_at_trnddc08>
>
>
> Yes. It comes with the word paradigm.
> Using simpler words may help to stay on topic.
>
>
>
> Earlier in this thread you said:
>
> > I would suggest even further isolation. The application solution
> > doesn't care if the data is in an RDB, an OODB, flat files, or clay
> > tablets. So one should hide the SQL as well.
> >
> > 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.
>
> and I asked you to point out the benefits of that approach.
> It seems I have to accept a - to me - wrong look at the role
> of schemata and databases to see those benefits.
>
>
> Earlier in this thread you said:
> > No, it is about solving problems (OO) vs. persisting data (data
> management).
>
>
> mm.: mutatis mutandis. Just try to fill it in.
>
>
> I think your issue was (because of
> "When the schemas and/or access paradigms change
> one does not have to touch the problem solution in any way."
> ) that hiding the data from the application isn't only possible,
> it is something to actually aim for. It isn't possible.
> In order to see that, the role of the schema should be explored.
>
>
> What did Bill buy the DBMS for. Is he stupid?
There is nothing wrong with me that could not be cured by a capful of Drano.
Date: Tue, 04 Jul 2006 15:00:17 GMT
Message-ID: <5ovqg.2646$283.449_at_trnddc08>
>>> ...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.
>
>
> Yes. It comes with the word paradigm.
> Using simpler words may help to stay on topic.
How does using something like 'conceptual model' rather than 'paradigm' help communication? The key to staying to staying on topic is to avoid tangents into orthogonal areas where the definitions also apply.
>
>> I also don't understand why you keep bringing up OO development; it is >> completely OT. The context here is about application partitioning >> where one isolates knowledge about data storage and access mechanisms >> away from the problem solution logic within an application. That is >> basic separation of concerns and modularization that one does whether >> the application is constructed with OO techniques or not.
>
>
>
> Earlier in this thread you said:
>
> > I would suggest even further isolation. The application solution
> > doesn't care if the data is in an RDB, an OODB, flat files, or clay
> > tablets. So one should hide the SQL as well.
> >
> > 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.
>
> and I asked you to point out the benefits of that approach.
> It seems I have to accept a - to me - wrong look at the role
> of schemata and databases to see those benefits.
I still don't see what this has to do with OO development. The benefits are the same benefits one gets from any software modularization: simplifying subject matters; containment, reuse, and -- most relevant for this thread -- context-independence.
>>>> 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.
>
>
> Earlier in this thread you said:
> > No, it is about solving problems (OO) vs. persisting data (data
> management).
I was qualifying by example because of your difficulty with common terms like 'problem solving'. I could just as easily have parenthesized FP, P/R, or any other software development approach to provide a contrast to 'data management.
>>>>>> 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. >> >> >> I don't follow this at all.
>
>
> mm.: mutatis mutandis. Just try to fill it in.
That doesn't help. I don't follow what you mean by the comment. What goes for OO as well?
>> 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 think your issue was (because of
> "When the schemas and/or access paradigms change
> one does not have to touch the problem solution in any way."
> ) that hiding the data from the application isn't only possible,
> it is something to actually aim for. It isn't possible.
> In order to see that, the role of the schema should be explored.
>
>>>>>>>>> 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.
>
>
> What did Bill buy the DBMS for. Is he stupid?
He bought a DBMS to store and manage data. Most commercial DBMSes today employ a paradigm that implements the RDM with RDBs.
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 Tue Jul 04 2006 - 17:00:17 CEST