| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: OO versus RDB
Responding to mAsterdam...
>>>> 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.
Why do you keep bringing up OO?
>> 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.
Exactly my point. For large, complex applications the benefits far outweigh the cost of (1) so there is effectively no decision.
>>>>>>>> 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?
OK, that's it for this thread. Making an incomprehensible statement and then asserting that you won't deign to explain what you really meant is not a good basis for rational discussion. Ta-ta.
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 Wed Jul 05 2006 - 09:58:39 CDT
![]() |
![]() |