Re: OO versus RDB

From: H. S. Lahman <h.lahman_at_verizon.net>
Date: Sun, 02 Jul 2006 15:26:10 GMT
Message-ID: <mARpg.780$iW2.643@trnddc03>

Responding to Frebe73...

>>>>>If the semantics of the old column "salary" are the same as the new
>>>>>column "baseSalary", why on earth would you need to change the name? If
>>>>>the name is not changed, no existing SQL statements would break. Only
>>>>>the applications that needs the new "burdenedSalary", would need to be
>>>>>rewritten.
>>>>
>>>>To capture the correct semantics of the attribute.  In a context where
>>>>one must distinguish between different flavors of salary, the original
>>>>name was poorly chosen and the DBA fixed that.  The attribute name is
>>>>supposed to reflect the attribute semantics.  Not changing it just leads
>>>>to opportunities for new applications to screw up later.
>>>
>>>
>>>Nothing forces you to change the column name. The solution will work
>>>with the old name. Would you change the name of the corresponding
>>>object property too, and break the interfaces? I don't think so.
>>>Changing column names is not a relevant motivation for decoupling SQL
>>>statements.
>>
>>As I said, you are missing the point.  The example was of the sort of
>>change that can break queries even though the accessed attribute
>>semantics was unchanged.

>
>
> If the semantics is unchanged, why does the attribute name need to
> change "to reflect the attributes semantics"? If the semantics is
> unchanged, the schema should be unchanged too. If the semantics change,
> both the schema and the "business logic" need to change.

The original name did not properly capture the semantics. That became obvious when burdenedSalary was added.

>>Why one would make such a change is not
>>particularly relevant,

>
>
> Of course it is relevant. Why should we protect the application from
> unnecessary schema changes? What you are saying is: I want to decouple
> my application from the schema because someone might do irrelevant
> changes to the schema.

No, what I am saying is that schemas change for reasons that are not relevant to particular applications.

>>though ensuring proper semantics for attributer
>>names is a valid reason (albeit often not a strong one compared to other
>>trade-offs like breaking existing applications).

>
>
> Above you wrote: "the accessed attribute semantics was unchanged". But
> if the semantics change, the application using the attribute need to
> change too.

I said, "proper semantics for attribute names". The name is not the attribute itself, but it should be consistent. The attribute's semantics was unchanged vis a vis the value it contained.

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 Sun Jul 02 2006 - 10:26:10 CDT