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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
