Re: OO versus RDB

From: H. S. Lahman <h.lahman_at_verizon.net>
Date: Sat, 01 Jul 2006 14:58:52 GMT
Message-ID: <M4wpg.109$Ym2.56_at_trndny05>

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.
>
>

>>However, that isn't the point. There are lots of ways to modify schemas >>without affecting individual attribute semantics.

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. Why one would make such a change is not particularly relevant, 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). The point is that such changes can and are made.

> Please give some more examples.
>
>

>>For example, I can
>>easily construct an example where the attribute is simply moved to
>>another table (e.g., to a new [EmployeeSalaryInfo] table, which is a
>>child of [Employee]).  The application query would still be broken.

>
>
> I assume EmployeeSalaryInfo and Employee has the same primary key. That
> is a totally unnecessary change. Nothing forces you to do that kind of
> change.

It will happen whenever (among other reasons) salaried employees are further subdivided due to changes in requirements that are reflected in different data domains for the attributes for different subsets of salaried employees. If the application only deals with the subset of salaried employees where the original semantics still prevails, the requirements change will not apply to it but its query will be broken anyway.

---

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 Sat Jul 01 2006 - 16:58:52 CEST