RE: [PHP] what PHP really needs
| From: | Marlon Moyer | Date: | Sun, 25 Jan 2004 00:31:09 +0000 |
| Subject: | RE: [PHP] what PHP really needs | ||
| References: | 1 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-175658@lists.php.net to get a copy of this message | ||
> -----Original Message-----
> From: John Nichel [mailto:jnichel@by-tor.com]
>
>
> 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.