Re: Databases as objects

On Dec 22, 4:21 am, Thomas Gagne <tga..._at_wide-open-west.com> wrote:
> Marshall wrote:
>
> > The interface to the database is the schema and SQL.
> > What do you think the interface is?
> After I've created a database for my application's data (let's pretend
> its a bookstore) I can either talk to it with low-level DML from
> applications
>
> INSERT (title, author)
> VALUES ("Complexity", "M. Mitchel")
> INTO catalog
>
> Or I can create a higher-level interface that knows something about my
> bookstore
>
> exec p_addBook _at_title="Complexity", @author="M. Mitchel"

Those two things you gave are just different syntax for the same operation. I can parse the one and generate the other in a fairly small amount of code. In fact I might be able to do it with a sed script. There is no difference in the "level" of the two.

On the other hand if you make 50 additional such domain specific procedures and compare them with full SQL, you will see the SQL interface is hugely more powerful, flexible, and yes, higher level.

> Additionally, I can ask the database to give me a list of its procedures
> (its interface), but without them all I have is its tables.

The tables (+ SQL) are substantially more powerful than any list of procedures you're going to come up with, until and unless the list of procedures expands in power and generality until it becomes the same as SQL. And then what was the point?

> True, I can
> tell a lot from the tables and a nice diagram, but I can tell a lot more
> from a list of procedures and their arguments.

A table has a name/predicate and a list of attributes.

A procedure has a name/predicate and a list of parameters.

Through what mechanism are you able to "tell a lot more" from the latter than the former? Isn't it possible that what you're experiencing is simply the comfort and familiarity of working with something you're used to instead of something you're not used to?

> That list of procedures is the interface I'm talking about. After
> populating a database with tables, views, and triggers, why keep talking
> to it using SQL when I can improve my application's interface to it by
> creating a domain-aware interface with intention revealing named procedures?

Since you premise is false, your conclusion is invalid. These "intention
revealing named procedures" are *restricted versions* of what you can do with SQL. And what is the database schema if not "domain aware?"

> True, I can do everything in SQL that I can do in procedures (they're
> written in SQL after all), but the procedures have an improved interface
> and protect the integrity of my model.

The procedural interface is necessarily crippled compared to the SQL interface. (Again, unless your procedural interface expands to be as large as SQL.)

You only think "improved" because you don't understand the superior mechanisms by which SQL protects the integrity of the model.

> I could also write whatever
> bytecodes SQL is compiled into rather than SQL, but SQL is an improved
> interface and protects the integrity of the relational engine. I could
> even access the database's data directly on disk, but SQL is an improved
> interface over the bytecodes which are improved over doing my IO.

Sure. That's the thing the OO crowd is unable to comprehend; that the OO computational model lies downward from SQL in the direction of raw bytes and assembly.

Marshall Received on Fri Dec 22 2006 - 18:31:26 CET