On 15 August 2011 19:43, LAMP <l...@afan.net> wrote:
> Hi all,
> This is THE question that bothers me for a while... I always was keeping
> session info, like user ID, organization ID, selected book ID... within
> $_SESSION array. Main reason is to access and maintain it faster than
> keeping them inside session table. And, also, one less mysql connection.
> Though, in last project the $_SESSION grow up to around 30, even 50 elements
> of the array. And several people mentioned it's better to keep so big
> session data in mysql than in $_SESSION.
> My question is pros and cons $_SESSION vs. mysql session. And, if the amount
> of data is only reason, when is better to keep all data in $_SESSION and
> when to store them in mysql?
> Thanks for any help,

An approach that I've seen recently is to use a nosql (Mongo in the
case I have in mind).

I'm not an expert on nosql, but the elements I understood from the
conversation I had were...

1 - The main purpose of the $_SESSION is to provide a user specific
storage. The structure of the $_SESSION is, more often than not, a
nested array of values.
2 - Converting the nested structure into a normalised set of tables
for a conventional SQL DB is a lot of effort in.
3 - More often than not, the data in the $_SESSION is only of use in
the session. So is there any point in having it in a DB (i.e. for
reporting/comparing/etc.). Maybe one or two values, but maybe not the
entire session.
4 - What happens if you are scaled to tens of thousand of realtime
users worldwide AND you are storing data in an SQL server - well,
replication, etc comes at a price.
5 - A no-sql store will store all the data for the session in 1
collection per user and therefore when you retrieve or save the
session data, only the structure specific to this user is altered
rather than potentially many rows in many tables, shared with many
other users, all generating their own changes.

The more I learn about no-sql (specifically using Mongo in PHP), the
more I think that this solves a lot of the problems with very large
sites handling very large number of users in many different countries.

Of course, only the "temporary" data should be in the session. Maybe
your shopping basket and any cached data (purchase history). Things
which you may need or have accessed in this session.

When you click the "purchase now" button, of course, that goes to the
permanent store. Orders are logged, payments made, stock dispatched,
etc. That and the analysis of that sort of transaction (OLTP after all
is about transactions), is the domain of conventional SQL servers.

But, it seems that no-sql is an excellent fit for long-term,
user-specific, cached session data.

And if you have replication based upon geography (I assume that this
is the most likely way to use replication beyond simply
scaling/processing power), then as long as you tune your users to the
right server, they will always have the latest version of their cached

Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to