There is no one simple answer to that. In some cases there may be a MUCH cheaper query than the one you would do to recover the data. MySQL for instance optimizes the query 'select count(*) from table' down to just fetching a variable containing the total rowcount. Even if you need a WHERE condition its often enough to check one side of a join, which can be orders of magnitude cheaper than a full query. You can also maintain summary tables in some cases that will allow you avoid expensive queries. Maybe you know that certain things only change once a day, so you can summarize them into a derived table or global server variables. Remember its pretty cheap to cache small amounts of data in memory on the web server as well, or in a global session object.
On Wednesday 19 February 2003 03:58 pm, Kjetil Kjernsmo wrote: > Hi folks! > > This question is slightly OT, since it is more about databases and DBI > than AxKit, but I figured more people must have run into it. > > When you code an exists or process sub in a Provider, that check against > a database to see if the entry you're after exists, how do you do > that...? > > I mean, this operation may be almost as expensive as retrieving the > entry itself from the database, unless you do something smart...? > So, if you first do an expensive operation to check if you process, and > then do pretty much the same thing again to retrieve the resource, it > seems like a waste... Right now, I've coded it to say "always exists" > and then throw an exception after retrieving the resource, but that is > clearly not the intended way. > > So, this smart thing I'm after, is there a cheap way to check if a row > exists? I'm using the Perl DBI and a PostgreSQL database. > > Best, > > Kjetil -- Tod Harter Giant Electronic Brain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
