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_at_trnddc03>
>
>
> 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.
>
>
> 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.
>
>
> Above you wrote: "the accessed attribute semantics was unchanged". But
> if the semantics change, the application using the attribute need to
> change too.
There is nothing wrong with me that could not be cured by a capful of Drano.
Date: Sun, 02 Jul 2006 15:26:10 GMT
Message-ID: <mARpg.780$iW2.643_at_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 - 17:26:10 CEST