Re: Databases as objects

On Dec 28, 11:38 am, Thomas Gagne <tga..._at_wide-open-west.com> wrote:
> kvnkrkpt..._at_gmail.com wrote:
>
> But I'm still having a communication problem in c.d.t. I
> actually think its a form of stereotyping: no matter what I say, because
> it uses the term "object" prejudice thinks I want to replace set
> processing with Java then take your little sister to the wrong side of
> the tracks.

I can see how it would appear that way, but I don't think this explanation
is correct. Note that most of what I do is OOPL; been doing it for 20 years. Every time I write application code, it's in a pure OO style. I've tried quite a variety of ORMs; some public ones, some proprietary ones. Wrote two myself. Wrote many by-hand OR classes. I have lots of experience with huge codebases written this way. And after many years of trying, I became convinced that this is *not* the way to go. The OO layering techniques, applied over SQL, has the effect of obscuring what's happening, and crippling the expressive power of the relational model, just when you need it the most. This has inevitable disastrous effects on performance. Ultimately it becomes very difficult to determine what queries happen in a given codepath without exhaustive tracing. That's something that should be immediately apparent, not obfuscated.

Furthermore, these problems aren't incidental or the result of a lack of discipline or undertrained programmers; I work with some of the best programmers in the industry. It is instead a direct consequence of the technique of encapsulating and abstracting the dbms and the relational model. You *cannot* wrap a high level abstraction inside a low level abstraction without crippling and obscuring the high level abstraction; it is fundamentally impossible.

Lately I've been writing applications in a style which makes no effort to hide the relational part. SQL is embedded directly where it is used. Function nesting is kept to a minimum: when you want to generate a page, you first get the data using various queries, then process it. The two are not interleaved willy-nilly. It works great and it achieves performance that is often described as impossible before the fact.

> I'm going to have to work on some examples so c.d.t. can see that what I
> propose to do doesn't require OOPLs or abandoning set processing.

By all means! However if you put a lot of effort into coming up with an example that demonstrates your point clearly, but ultimately fail to do so, please be willing to consider the possibility that your hypothesis
is invalid.

Marshall Received on Thu Dec 28 2006 - 23:17:49 CET