Re: OO versus RDB
Date: 28 Jun 2006 11:11:41 -0700
Message-ID: <1151518301.178795.291300_at_b68g2000cwa.googlegroups.com>
H. S. Lahman wrote:
> The point is that data management and problem solving are quite
> different concerns and activities.
Perhaps part of my problem is the absolute vacuousness of the word "management."
> I didn't look because it is irrelevant to the discussion. The issue is
> not about finding an alternative to SQL for accessing an RDB. (Though
> clearly if one is using flat files it is not the best choice.) It is
> about hiding /whatever/ access mechanism one uses.
> However, outside CRUD/USER processing the solution to a particular
> problem will almost always have a different representation of the data
> than the DBMS so that it can manipulate the data optimally for the
> solution in hand.
Whether these "problems" have different "representations of the data" is irrelevant to whether they should have, or need, different representations; but even more critical is that the canonical form be reliably specified, and offers flexible operators. Given these specifications and operators, why should we water them down within applications?
> The persistence mechanisms should be completely transparent
> to the problem solution in the same sense that a particular problem
> solution should not matter to the way data is managed on the enterprise
> level.
Like a duplicate tuple, seeing this statement again and again doesn't make it any more true.
> In a non-CRUD/USER context I have a complex problem to solve. To do
> that I have to manipulate data in data structures tailored to my problem
> solution.
> Those data structures are <usually> initialized by data
> acquired from a persistent data store. But the access of the data to do
> that initialization is quite independent of the problem solution.
Access may be irrelevant, but WHAT you get back is very relevant.
> IOW, both the problem solution and the data access are "the code". They
> are separated by logical modularization and decoupling to make the
> application easier to implement and maintain.
>
> I really don't know why this notion of separation of concerns is such a
> novelty.
> Modularization has been a basic part of large scale software
> development since the '60s and there is nothing particularly OO about it.
True.
> That's not the issue. Any time one makes /any/ change to an application
> there is a potential to insert a defect.
A meaningless statement.
> One reason one separates
> concerns is so that the insertion defects is isolated and limited in
> what can be broken.
> If you don't touch the problem solution code nor the interface it uses
> to access the data it needs, then you can be confident that you didn't
> break the solution logic.
Wrong. It depends on WHAT data it's getting.
> Then all you have to demonstrate is that the
> persistence access subsystem still provides the same data values it did
> before the change to it.
Values in what form?
> Again, this sort of modularization, decoupling, test management, and
> defect prevention is really basic software development stuff once one is
> outside the realm of CRUD/USER pipeline applications.
"Basic" does not imply easy. Decoupling and modularization are words that are easy to toss about without understanding their costs relative to benefits, and the contexts in which they apply.
Each line of code is separate; isn't that enough decoupling? I can replace "x = x + 1" with "x++" if I like, so isn't that line of code decoupled from those surrounding it?
> >> 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.
Think about it for a while; it is true, and has interesting implications.
- erk