Re: Databases as objects

From: Marshall <marshall.spight_at_gmail.com>
Date: 22 Dec 2006 10:32:53 -0800
Message-ID: <1166812373.060468.188420_at_42g2000cwt.googlegroups.com>


On Dec 22, 9:11 am, Thomas Gagne <tga..._at_wide-open-west.com> wrote:

>

> But now I'm confused why the value of evolving loose SQL to functions
> seems to escape c.d.t. Perhaps we're talking passed each other?

No, we understand you just fine. You're just proposing something that's not as good as what we already have, so we don't agree.

(By the way, there have been various other sorties from comp.object proposing exactly the same thing.)

What with firefox crashing I've lost track of what it was in response to, but I wanted to make a few more points:

The idea that various applications in diverse languages will need to use the exact same query, and that when query instance 1 in application 1 changes, query instance 2 in application 2 will change in the same way, does not occur in the real world in my experience. Applications are written for different purposes, and hence they don't use the same queries except in the most trivial cases. A trivially reusable query might be

  select * from Customers where CustomerId = ?

but there's no point in wrapping such a query in a procedure:

  selectStarFromCustomersWhereCustomerIdIs(int customerId)

(or you could give it a shorter name.)

But supposing we did have a query that was so ... something that we just had to abstract the query itself and make it available to diverse applications. We could

1) write it as a procedure in every host language,
2) use a stored procedure or
3) make a view

Using 3 means that application code can query it exactly as it would any other table, so the mechanisms for access remain uniform. And in the unlikely event that we want to change its semantics in a way that doesn't change its type, (which is the most we could do with a procedural interface) we can do so without modifying any client code.

An enterprise database is much like a library interface, and application programmers don't have much experience with many-client library interfaces. They see that interface modifications are difficult in an enterprise database and assume that that must somehow be the fault of SQL rather than an attribute of library interfaces in general. However I have spoken with e.g. some of the team that wrote the Java core API and they report exactly the same difficulties with interface changes. In fact they tend to have a more extreme take, in that they say that once an interface is released you pretty much can *never* modify it.

Marshall Received on Fri Dec 22 2006 - 19:32:53 CET

Original text of this message