Re: OO versus RDB

From: H. S. Lahman <>
Date: Sat, 01 Jul 2006 16:05:46 GMT
Message-ID: <u3xpg.168$8U1.32_at_trndny07>

Responding to Marshall...

>>>>It breaks the query, but not the problem solution that needs the data.
>>>This sounds sensible, but isn't. Any schema-change breakage
>>>will affect both query and code. If a queried column is deleted,
>>>the query will need changing, but also the code has to reconsider
>>>what it will do in the absence of the column.
>>I'm afraid that is not true.  Consider
>>[changing the name of an attribute]

> Sure, if the change is trivial (in that it has no associated

> change in semantics) it might not be the case that
> anything besides the query needs to change. You don't
> even need a view, just change "SELECT salary, ..."
> to "SELECT base_salary as salary, ..."

While trivial it does reflect a change to the client and any change to the client presents an opportunity for inserting a defect that will render the problem solution incorrect. My issues in this thread are change management and defect prevention on the client side. One way to address those issues is through modularization that decouples the data storage and access mechanisms from the problem solution logic. IOW, one wants to encapsulate things like SQL query construction away from the problem solution logic to ensure that at least some changes on the RDB side cannot affect the problem solution.

> What about adding a new attribute that the application code
> needs to use? What about deleting an attribute that has
> no obvious default? What about moving an attribute to
> a different table such that its cardinality relative to the
> query changes?

In your first example, the application solution requirements would have to change for the solution to need a new attribute in the RDB schema. Similarly, deleting an attribute that the application needs would cause serious problems for the application solution. So these are examples of requirements changes that do affect both the solution logic and the schema.

The issue here is whether changes to the RDB schema are possible that do not affect the problem solution logic (i.e., it manipulates the same data in the same way before and after the schema change). Such changes would affect query construction code but not the problem solution code.

Your last example is one where the query breaks but not the solution logic (assuming the attribute semantics is not affected by the change in location). (I actually used a variant of that example responding to Bertilsson.)

There is nothing wrong with me that could not be cured by a capful of Drano.

H. S. Lahman
Pathfinder Solutions -- Put MDA to Work
blog: Pathfinder is hiring: (888)OOA-PATH Received on Sat Jul 01 2006 - 18:05:46 CEST

Original text of this message