Re: Decouple SQL queries from class in OOP design

> 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.
Applications should interact using messages. For example, a common
pattern in many enterprise applications is to have separate production
(transactional) database and datawarehouse databases. A data mining
software does not interact directly with the production databas.

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

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

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

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

Fredrik Bertilsson
http://butler.sourcefore.net

.

Relevant Pages

  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... But SQL does not have a pointer data type or the ... > being told to design a database. ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: DBMS and lisp, etc.
    ... Naively implemented with SQL, again for 10 ... (1 query for the initial orders, 1 query for each order for its ... soon as you upgrade to the SQL database. ... (eq (order-customer orderA) ...
    (comp.lang.lisp)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... a surrogate key should support the primary key. ... But SQL does not have a pointer data type or the ... > being told to design a database. ...
    (comp.databases.theory)
  • Re: dbdebunk Quote of Week comment
    ... But SQL does not have a pointer data type or the ... More and more programmers who have absolutely no database training are ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: Just say no to threads [Was: Software architecture]
    ... they knew there was going to be a database in the app. ... Now my colleague just spent a couple/three weeks designing an SQL ... Turns out they have a flat file of sample information, ...
    (comp.object)