Hi Jochen,
The query in question doesn't change, the user has other criteria that would change as they narrow their search. That was the question I started with, I was coding the saves to session variables on GET and the retrieve on POST and I wondered if mysql would be doing it for me anyway, however there has been some really good discussion and a number of angles that I hadn't even considered. Richard _____ From: [email protected] [mailto:[email protected]] On Behalf Of Jochen Daum Sent: 02 February 2010 20:31 To: [email protected] Subject: Re: [phpug] Re: PHP session variables vs database cache If the queries don't change would this be covered with the right amount of mysql cache? Assuming you are in control of that? Kind regards, Jochen Mobile: 021 567 853 Phone: 09 630 3425 Email: [email protected] Skype: jochendaum Web: www.automatem.co.nz On Feb 2, 2010 7:47 PM, "Bruce" <[email protected]> wrote: Hi Richard, I totally agree with you that you want to keep the processing as close as possible to the data source. The performance limiter between the database and the application is of course the network or the TCP stack if you are hosting the database on the same server. The less data you can transfer through this bottleneck the better for the performance of your application. But like you say, each application has its own set of variables and pressures that put the architecture in one direction or another. In our particular case our data model is essentially a tree of objects that can have virtually any number of levels. Together with that there are multiple additional relationships between objects. Then of course is does not help that our users can script their own report templates :-) Cheers, Bruce -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email t... -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected] -- NZ PHP Users Group: http://groups.google.com/group/nzphpug To post, send email to [email protected] To unsubscribe, send email to [email protected]
