Re^3: Architectural question...

[raafschild]

This certainly is a fruit of a different kind ;-).

You might want to store the results of the query in a summary table and have that table maintained by a set of triggers on the data table. That way the persistence and the caching is handled by the database, so you don't have to write it yourself.

Queries on this summary table should by quick, and all changes in the data table are immediately available in the summary table.

Sorry for a not very perlish suggestion in this forum.

Raafschild

[devnul]

Its starting to drive me bananas... (sorry, I could not resist)

The problem with storing it using triggers/materialized views is that the "where" clause against the data table is not constant. Sometimes I am searching the data table for records in a state, zip code radius, full-text search (using tsearch2), and about 3 other factors. So the "grouping" has to happen *AFTER* the result set is limited by the WHERE clause against the data table.

.. I hope I explained that well enough...

- dEvNuL