[thelist] php/mysql speed

rudy r937 at interlog.com
Mon Apr 8 16:11:01 CDT 2002


> 'products' is a table with about 100 items in it.

you're going to have all 100 listed in some kind of nav bar?

> That way, I have the result set that I need to build
> the nav available on every page, right?

i don't know php but you're probably on the right track

look for some way that each page doesn't have to know whether it's
accessing the database (if you know what i mean) -- for example, coldfusion
has query results caching, whereby each page calls the query as it normally
would, but the coldfusion server says aha, i already have these results,
here ya go, and pulls them out of query cache rather than calling the
database again

classic example is extracting state/province codes from the database --
every time you need state/province, just code the state/province retrieval
with a query that has caching parameters on it, and let coldfusion figure
out whether it has to go to the database -- this is so much nicer than
coding the logic yourself to retrieve and store the data somewhere (e.g.
application scope)

dunno if you have the same flexibility in php, if you don't then use an
include module where you can localize and special logic over and above the
uery itself

> My other idea was to let the product update script (where prodName,
> prodCategory, etc get updated) build a static navigation file and then
> just include that file.

also works, but i'd only do that if it was easy to trigger

> I don't know what's slower, a query to the db or a disk
 > access to include a file.

definitely the query is slower

> Is there some commonly accepted 'best practice' for the
> kind of functionality I'm working on?

i'm totally behind the "what works" strategy (good one, hans)


rudy




More information about the thelist mailing list