tedd wrote:
At 4:01 PM +0000 3/13/08, Stut wrote:
tedd wrote:
Then, when the user returns, you simply check the cookie with what's
stored in the dB and continue as before. If the check fails (no
session id or it has been altered), then start again.
Because that negates the whole point of doing it which is to reduce
database access to the minimum possible.
Oops, I guess I missed the whole point of your article.
You want to minimize dB usage by using an encrypted cookie so that when
users return, that action doesn't use the dB.
But, once the user is on, then everything they request in the form of
unique data is provided by the dB via their user id, correct? So, you
saved one trip to the store, but how many trips to the store does a user
usually make? And is that worth it?
Not being critical, just wondering.
As I state in the article most of the site is the same for all users
whether logged in or not. If the user is logged in then we should a menu
in the left column which displays their name. We also pre-fill some
forms with their name, email address and phone number.
That means that to remove the need to access the DB on every request for
logged in users on most of the site we just need to store their name,
email address and phone number between requests in a way that doesn't
involve the database. That is the problem the technique in the article
solves.
It's true to say that when the user is in the members area most page
requests will need to hit the DB, but as stated that amounts to less
than 30% of page views on any given day. The end result is that DB load
is now at an acceptable level without compromising the user experience.
Hope that makes sense now. If not I'm happy to explain further.
-Stut
--
http://stut.net/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
