Re: Decouple SQL queries from class in OOP design

"frebe" <fredrik_bertilsson@xxxxxxxxxxx> writes:
> > If the data is owned by the application, embedding SQL might be
> > justified. In most environments of even slightly above trivial
> > levels of complexity, information such as this is maintained in a
> > database that is shared across the enterprise.
>
> In a god architecture, the database is owned by the application.

That absolute assertion is incorrect. Many systems that provide
significant, measurable business value are based on architectures that
include an enterprise or otherwise shared database.

> Applications should interact using messages.

This is another absolute assertion that is not correct in all
cases. Message passing is one valuable technique, but it is not
universally applicable.

> > It couples the application to the database schema. Changes to
> > the schema (due, for example, to requirements of completely
> > different applications or database administrator decisions) could
> > break the application.
>
> Can you please some example of this? Besides, your application will
> break anyway.

I'm surprised you would need examples. Database schemas change
for a wide variety of reasons, including support of new applications,
support of modifications to existing applications, and optimizations
made by DBAs, to name just a few. If the application is coupled to
the schema then yes, changes to the schema could definitely impact the
application. If the application is properly decoupled, it is less
likely to "break anyway".

> > The "validate employee ID" functionality is likely to be used in
> > more than one application. Encapsulating it as a reusable
> > component or service reduces the complexity of each application
> > and provides more consistency across the enterprise.
>
> Why would this not be possible if you are emedding SQL in your
> application?

Because SQL embedded in one application is not reusable in
another. That seems obvious.

> > Embedded SQL requires more than a simple SQL statement. The
> > application must deal with database connections, transactions,
> > cursors, etc
>
> Connection, transaction and cursor handling can still be done by
> pre-made generic class libraries. This has nothing to do with
> embedding SQL.

The point is that decoupling the application from the database
allows the application developer to focus on _why_ he or she is using
the "validate employee ID" functionality rather than on the mechanics
of how to validate an employee ID. Encapsulating the overhead
associated with using the DBMS is necessary to provide this
decoupling.

> > Encapsulating SQL in components or services that expose required
> > functionality instead of the underlying database schema makes
> > impact analysis much more straightforward and reliable. When SQL
> > is embedded in applications across the enterprise, it becomes
> > virtually impossible to determine the effect of any proposed
> > change to the database schema.
>
> Adding tables and columns will not effect existing clients. Removal
> of tables or columns will, but it will most likely also change the
> service API and give you the same problem with finding all clients
> to the service API methods.

Not all schema changes will affect the functionality supported by
the database. Decoupling the provision of that functionality from the
details of how it is implemented allows the same functionality to be
provided by a wide variety of different underlying implementations.
Coupling an application to a database schema makes the application far
less resilient to change.

Frankly, I'm don't understand your purpose in replying to my
original post. Are you seriously suggesting that tightly coupling an
application to a database schema is good practice?

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: Win32 Needs
    ... VB applications would be using the BDE through ODBC and NexusDB ... They too are pushing towards ANSI SQL compliance. ... contract I defined my database schemas in my own xml format. ...
    (borland.public.delphi.non-technical)
  • Re: Decouple SQL queries from class in OOP design
    ... > If the data is owned by the application, embedding SQL might be ... the database is owned by the application. ... Why would this not be possible if you are emedding SQL in your ... > effect of any proposed change to the database schema. ...
    (comp.object)
  • Re: If you were developing a database in Forth...
    ... John Passaniti wrote: ... blown database system is dumb. ... application necessarily maps well to a relational model or that SQL ... If you don't need all that power or the standardized interface (and most applications, particularly embedded ones, don't) there are much better alternatives, either pre-existing or, in some cases, a simple custom development. ...
    (comp.lang.forth)
  • Re: Question regarding OOP and database access
    ... trying to ensapsulate access to one table inside one class is ... There are two kind of changes that can be made in a database schema: ... all old SQL statements will still work. ...
    (comp.object)
  • Fwd: Module submission DBIx::DB
    ... extend DBI itself, or bundled inside a larger package (Catalyst, ... DBI Database schemes with perl interfaces ... - A database schema, and - A perl interface to that database schema ... but as it stands, there is no DBIx::UserDB distribution, instead ...
    (perl.dbi.users)