Re: Decouple SQL queries from class in OOP design

On 22 Nov 2005 10:46:53 -0800, Mikito Harakiri wrote:

> Patrick May wrote:
>
>> - Embedded SQL requires more than a simple SQL statement. The
>> application must deal with database connections, transactions,
>> cursors, etc. Encapsulating this overhead and allowing it to
>> be reused across multiple applications reduces the complexity
>> of each application and the opportunity for bugs to be
>> introduced.
>
> If you have any difficulty opening database connection, or iterating a
> cursor, you may think refreshing your programming skills. Those are not
> the kind things that are worth abstracting.

Are applications built around DBs or vice versa?

Not only the cursor but DB as a whole is a subject of abstraction. The very
idea of separation of data (whether it be physically, logically or
descriptively on the language level) is not conform to the view on software
design principles people like me are counting for modern. It is a clash of
civilizations, if you want. Arguments don't work here much. (:-))

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: Read a FILE
    ... In embedded SQL, a cursor is kind of like a SETLL followed by a READE loop. ... I am using logical file to same file at the 2nd time and keep record ...
    (comp.sys.ibm.as400.misc)
  • Identity Column Question
    ... I am relatively new to using embedded SQL in RPG so please forgive me ... declare a cursor, fetch the cursor and perform it's processing logic. ...
    (comp.sys.ibm.as400.misc)