Re: Relational-to-OOP Tax

Schemas change for different reasons than application code.

Hogwash. Can you prove this? Didn't think so.

Easily. Two examples off the top of my head, from recent
projects:

- The schema changed to support the requirements of a new
application. The existing applications did not require
the new data and so should not need to change, in a
well-designed system.

Is this a proof? You added data to the database? New columns and new
tables? In what way would that affect the other old applications? If
the old application doesn't need the new data nothing has to change?

It's a description of one reason why the schema may change for
different reasons than the application, just as Bryce Jacobs asked
for.

Your original statement was: "Schemas change for different reasons
than application code. Coupling the application to the schema makes
change more difficult and risky."

In what way is it risky or more difficult to make changes if the
application is coupled to the schema, in this example?

If the application were decoupled from the schema, it wouldn't
have to change at all. Only the mapping layer would need to be
retested. There would be no opportunity to introduce bugs in the
application logic.

In your example, you are adding data (columns and tables?). No
existing SQL statements will break if you add columns or tables. Your
example is not an example of there decoupling SQL statements would
help.

I note that this is another tangent. My point that applications
and schemas change for different reasons has been demonstrated.

No. You stated "Coupling the application to the schema makes change
more difficult and risky." That has not been demostrated.

- The schema was denormalized to improve performance. The
functionality implemented in the application should not
need be impacted.

A database should be normalized.

Yes, in an ideal world. In the real world, hardware and
software constraints sometimes prevent performance requirements
from being met without sacrificing some purity.

The main point, again, is that this is an example of the
schema changing for different reasons than the application.

And I showed you a solution (materialized views) that would not
break any existing SQL statements.

I don't recall this,

http://groups.google.com/group/comp.object/tree/browse_frm/thread/06ed010286143585/62c3d2e4513e6071?rnum=191&_done=%2Fgroup%2Fcomp.object%2Fbrowse_frm%2Fthread%2F06ed010286143585%2F51231cc89eb34c3d%3F#doc_d161900e66be4c6e

/Fredrik

.

Relevant Pages

  • Re: Relational-to-OOP Tax
    ... well-designed system. ... In what way would that affect the other old applications? ... "Schemas change for different reasons ... Coupling the application to the schema makes ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... remains that the schema and applicaton code change for different ... different reasons than application code". ... Multiple applications may use the same ... A change in the schema to support application ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... In what way would that affect the other old applications? ... "Schemas change for different reasons than application code. ... Coupling the application to the schema makes change more difficult and ... In what way is it risky or more difficult to make changes if the ...
    (comp.object)
  • Re: Relational-to-OOP Tax
    ... remains that the schema and applicaton code change for different ... different reasons than application code". ... Multiple applications may use the same ... A change in the schema to support application ...
    (comp.object)
  • Re: Decouple SQL queries from class in OOP design
    ... > Of course there are existing applications that uses many different ... > architectures and still provides measurable business value. ... > should access every database directly. ... by the database, but the schema changes. ...
    (comp.object)