Re: OO versus RDB

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