Re: Databases as objects

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Fri, 22 Dec 2006 18:55:04 GMT
Message-ID: <cSVih.36310$cz.535342@ursa-nb00s0.nbnet.nb.ca>

Marshall wrote:

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

And it is dependent on the limitations of the procedure. The procedure can only add a single book at a time, for example. And it is dependent on the limits of the language which calls the procedure. Received on Fri Dec 22 2006 - 12:55:04 CST