| Re: Best strategy for creating an application scoped variable? [message #172043 is a reply to message #172035] |
Fri, 28 January 2011 07:30   |
Denis McMahon
Messages: 634
Registered: September 2010
Karma:
|
Senior Member |
|
|
On 28/01/11 03:24, Jerry Stuckle wrote:
> On 1/27/2011 9:40 PM, Peter H. Coffin wrote:
>> On Thu, 27 Jan 2011 16:08:01 -0800 (PST), laredotornado(at)zipmail(dot)com
>> wrote:
>>> I'm using PHP 5.2. I would like to populate a hash from a database
>>> query. The hash should be available to all users of the application
>>> and would only be updated very occasionally. The database query is
>>> expensive, and I would prefer only to run it once, whenever PHP was
>>> restarted, or on the rare occasion when the database data changed.
>>> What is the best strategy for implementing this hash?
>> I'm confused. What "hash" do you want to "populate"? Do you just want to
>> stick a pregenerated value in a table? Maybe you need an insert/update
>> trigger?
> That was my thought - create a table in the database with the required
> information and update it based on a trigger. Much easier than trying
> to use shared memory or the like.
> I guess an alternative would be to create a PHP file from the generated
> data and include it where necessary. But there's always the problem of
> updating it when the web server restarts (PHP doesn't "restart" - it
> starts every time a request is made for a PHP file - and only then).
I guess the included file could be created with a cron job, say every 6
hours or so?
To try and minimise file access conflicts, it might be best to create it
with a temporary name and then using a shell "mv temp_file actual_file"
at the end of the cron job.
However, I'd have thought that copying the query results into a new
table would be the best answer, I guess it would be a static snapshot of
the expensive query, and then access it as "select * from <table>",
maybe running a cron process to generate it every 6 / 12 / 24 / whatever
hours.
Or create an extra table with a time field that you update when you run
the query, and check this field every time you access the data, if the
data is older than some defined limit, call the expensive query to
update the snapshot table.
Rgds
Denis McMahon
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]