Re: Efficiency vs. code bloat for SELECT wrappers

Sam Mason wrote:
> Luckily I've been able to design most of the programs I work on as
> relatively simple layers over a database, I'm not sure if you're able to
> work like this.

I'm not at liberty to divulge much of the application concept, but
consider, if you will, an application like Gmail or any other web-based
mail service.

I'm venturing a guess that the database code in Gmail scripts isn't
overly-complicated, and there are probably a handful of "task
categories" that get executed by the application.  Folder operations
might be lumped into one category, and SMTP operations into another, for
example.  Each category probably has a few variations, like retrieving
an email with or without full headers.  Overall, though, I would wager
that the front-end, UI-type stuff in Gmail is much more complicated than
the database code, especially with all the Javascript it uses (though, I
suspect most of that is relatively static code).

This is roughly the distribution of code I'm implementing: lots of web
stuff with only a few database hits per page, most of which are SELECT
queries.

So, really, I don't think my application would be considered to be
"relatively simple layers over a database", since the UI part will be so
full-featured.  I doubt I would ever see 5-10% of the lines accessing
the database in this application.  A better estimate would probably be
around 1% or 1.5%.

My guess, having written this, is that your approach might be more
useful for applications that rely heavily on interaction with a
database.  I'd appreciate any more comments you have on this, though.

Colin