Re: Databases as objects

On Dec 22, 6:29 am, Thomas Gagne <tga..._at_wide-open-west.com> wrote:
> As long as the DB's model can change, even
> trivially, without impacting the framework or the application, I've no
> objection.

Can your proposed procedural interface change its signature without impacting applications? No it cannot; the way decoupling works is we couple to an interface instead of to an implementation, and the schema is the interface to the database.

For two modules to work together they have to agree on *something* and that thing they agree on can't change without both of them changing.

> Here is what I think the first problem is: now the application has
> become dependent on the physical design of the database. It's dependent
> on the existence of a table named T_Person and that the table has the
> columns name, age, and ss#.

The database schema is *logical* design, not physical. The physical design of the database is the in-memory and on-disk data structures the dbms uses. It would indeed be a bad idea for an application to access those directly. Fortunately the dbms provides us with an abstract logical interface to these: SQL.

Again, if an application uses your procedural interface, it has become dependent on the existence of a procedure named add_book and on that procedure having parameters "book" and "author". Etc.

Marshall Received on Fri Dec 22 2006 - 19:03:02 CET