> -----Original Message----- > From: John Nichel [mailto:[EMAIL PROTECTED] > > > The problem I have with this is where the database DOES change, and not > on any set interval. I used to work at Insight, and our product > database changed constantly, at any give moment to account for pricing > changes, stock changes, specials, updates from places like TechData, > etc. If I'm caching the results of my query, I miss those updates, and > have a customer placing an order for a product at the wrong price, out > of stock, etc.
[Marlon Moyer] This isn't a situation that you would use a cached query. You would only use it when something doesn't change that often, or you have control of when it changes. > > Now I can somewhat understand the use of this on a db that rarely > changes, depending on how often rare is. Or in a case where the db is > updated at a set time. Still, if rare is a time period of months, why > have a db anyway? Static HTML would be faster than php, cold fussion, > etc. And if the db is updated at a set time, what happens when I have > to push a change out that is outside of the set time? > > Maybe it's just me, but I feel that the db is supposed to handle the > dynamic data, not the web server. > [Marlon Moyer] My time frame is usually once or twice a day. I've set up admin pages that will refresh the queries on demand, or the pages themselves update the db and then refresh the query. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
