On 15 August 2011 19:43, LAMP <lamp@xxxxxxxx> 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, > LAMP 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 data. -- 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
