Re: Databases as objects

Neo wrote:
>> What I realized while trying to describe my preference to use DB procedures as the primary (re: only) interface between my applications and the database is because I believe my DB's physical representation of data belongs to it alone and that customers of the DB oughtn't be permitted to directly manipulate (change or query) its data.
>>
>
> Usually one prefers to use high-level interfaces. Below might be some
> reasons one utilizes a lower-level interface:
> 1) Impossible or impractical to do via high-level interface.
> 2) Lack of performance.
>
>
I agree programmers usually prefer higher-level interfaces. Usually, and I think erroneously, that meant trying to map objects to database tables and rows and trying to instantiate objects from the database and persist them to the database. That mapping is a source of frustration for programmers but a source of revenue for consultants and framework vendors.

It is also a source of conflict between OO and Relational acolytes.

Numerous frameworks and "patterns" exist that try to ease object-relational mappings and IO, but they ignore the 800-lb gorilla in the room: the database exists and exists separately from applications. A database' model is static--it doesn't change for each of its consumers. An object model doesn't have to be static--it can change to be whatever is optimal for a specific task.

Why don't we exploit that?

In the system's I've written there's never been a single program--there's usually dozens. Each one has the possibility to define the best object model to suit the program's task. Neither are the programs written in a single language. At InStream both Smalltalk and PHP are currently used--and only a few years ago Python was also used. Should the object model have been the same for all three? Should the high-level interface been the same? Should a separate framework been used for each?

Programmers and designers shouldn't ignore the potential variety of their client programs, nor restrict each program's language unnecessarily. Investing heavily in a framework can do just that. Even if PHP is better for something than Java, a heavy investment in Java frameworks may force square programs into round infrastructure.

When I look at the concepts of high-cohesion within an object and low coupling between objects I think I see remedies to both your points above. Things that are impossible or impractical to do in a high-level language may be better implemented inside the DB using SET operations. Why update each row individually when I can update them all at once?

That which is impractical may also suffer performance problems, but performance alone isn't a reason to do anything (unless that performance is so poor as to make something unfeasible). However, being able to improve performance in one place (like a procedure or view) is preferred to needing editing SQL sprinkled throughout an application or toolkit. Received on Thu Dec 21 2006 - 19:56:05 CET