Re: Decouple SQL queries from class in OOP design

"Mikito Harakiri" <mikharakiri_nospaum@xxxxxxxxx> writes:
> 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?

As noted in another part of this thread, you'll have a problem
with the proliferation of views over time.

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

That is not compatible with the usual definitions of "reuse" with
which I am familiar. The problems related to copy-and-paste are
well-known to seasoned software developers. Suggesting it as a good
practice flies in the face of a great deal of experience.

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

I have shown no preference. I am well aware of the capabilities
of views and stored procedures in this area. The issue I'm
discussing, though, is the problems that arise from coupling an
application to a database schema.

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

Alternatively, you could refrain from your implied insults and
explain why you disagree that the particulars of a schema are an
implementation detail. I think I've made it clear why I hold that
view.

Sincerely,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | The experts in large scale distributed OO
| systems design and implementation.
pjm@xxxxxxx | (C++, Java, Common Lisp, Jini, CORBA, UML)
.

Relevant Pages

  • 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: Decouple SQL queries from class in OOP design
    ... There is no change to the functionality supported ... > by the database, but the schema changes. ... > Denormalization for performance, as noted above, will definitely ... serioulsly chllenge his SQL tuning abilities. ...
    (comp.object)
  • Re: Dataset without a database - editing the .cs file
    ... functionality you want to add, and on the scope of the project. ... > I see that I can create an .xsd file at VS.NET will create a corresponding ... > autogenerated from my schema to add some functionality. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: How do I script object creation?
    ... For those unfamiliar with the functionality, ... objects, across any schema, and SQLserver will automatically generate ... all DDL for creating the object (in the case of tables and indexes, ...
    (comp.databases.oracle.misc)
  • Re: Critique of Robert C. Martins "Agile Principles, Patterns, and Practices"
    ... "The database schema and the application logic change for different ... isn't precisely because your code and schema are too tightly coupled. ... solution won't permit it) or a design flaw. ... for different reasons" instead of word it as a fact. ...
    (comp.object)