Re: Decouple SQL queries from class in OOP design

Patrick May wrote:
> Denormalization for performance is a change I've seen on more
> than one occasion. There is no change to the functionality supported
> by the database, but the schema changes. If the application is
> coupled to the schema, it too would need to change for no other reason
> than the coupling.

Ahem? If you denormalize for performance, then you have to provide
backward compatible views. Besides, are you aware of materialized
views?

> Denormalization for performance, as noted above, will definitely
> break existing SQL. DBAs may also change the schema to support other
> applications, for example by moving some columns from one table to a
> new table in order to change a 1:1 relationship to a 1:M. Such
> changes are not uncommon in large integrated systems.

If somebody uses denormalization for performance too often, I would
serioulsly chllenge his SQL tuning abilities.

> > > Because SQL embedded in one application is not reusable in
> > > another.
> >
> > If they are using the same database schema, it is obviously
> > reusable.
>
> Not unless you consider copy-and-paste to be reuse. If you are
> suggesting instead that one application expose the functionality that
> is implemented internally as embedded SQL then we seem to be agreeing
> that the embedded SQL should be encapsulated and exposed as a service.

Yes copy-and-paste is a reuse. The second code instance could be easily
tuned to seve a slightly different pupose. Oh, modifying the code is
horrible, I forgot. You have to subclass and redefine the method.

BTW, leveraging common SQL quieries via database views is also reuse,
which you seems prefer to totally ignore.

> A particular schema is an implementation detail. The same
> functionality can be supported by a variety of schemas, more than one
> of which can be in third normal form. Applications that depend on
> functionality rather than schemas are more resilient to change than
> those that are coupled to the implementation represented by one
> particular schema.

If the database schema is "an implementation detail", then the
conversation is over. Any good book on fundamentals of data managenet
could help.

.

Relevant Pages

  • Re: Decouple SQL queries from class in OOP design
    ... If the data is owned by the application, embedding SQL might be ... - It couples the application to the database schema. ... - The "validate employee ID" functionality is likely to be used ...
    (comp.object)
  • SQL Adapter Disassembling Result Sets & Dynamic Parameters
    ... properties of the schema returned in my orchestration. ... Also after processing all the records returned by SQL adapter in my ... from the toolbox drag an xml disassembler ...
    (microsoft.public.biztalk.general)
  • SQL Adapter Disassembling Result Sets & Dynamic Parameters
    ... properties of the schema returned in my orchestration. ... Also after processing all the records returned by SQL adapter in my ... from the toolbox drag an xml disassembler ...
    (microsoft.public.biztalk.server)
  • Re: Decouple SQL queries from class in OOP design
    ... suggesting that you can raise application abstraction level to the ... > functionality and _when_ to invoke that functionality. ... If I change the schema, ... > encapsulating the business functionality required in one place? ...
    (comp.object)
  • Re: Select Statement with 4 tables help required please
    ... > legal SQL syntax to use the same name for both a table and a scalar. ... > data element name would be used in the entire schema. ... I have a livingroom television and a bedroom television. ...
    (microsoft.public.sqlserver.programming)