On Mon, Aug 15, 2011 at 2:36 PM, Stuart Dallas <stuart@xxxxxxxx> wrote: > > On 15 Aug 2011, at 20:28, LAMP wrote: > > > > > On Aug 15, 2011, at 2:11 PM, Philip Thompson wrote: > > > >> On Mon, Aug 15, 2011 at 1:43 PM, 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 > >> > >> Hi all. Long time no see. I personally think 30-50 elements in an array > is not a lot of data (unless you're storing hundreds of megs of data per > element). You really have to weigh the pros and cons of using file-based > session storage versus database session storage. With a quick google search, > this article by Chris Shiftlett came up: > http://shiflett.org/articles/storing-sessions-in-a-database. Specially > look at the background section. It goes over a couple reasons to use a > database. While this list is not exhaustive by any means, it should get you > thinking. If the biggest reason for wanting to use a database over the file > system is because of the space, then you may want to reconsider.... > >> > >> In file-based session storage, the session data is saved in a particular > location (as specified in php.ini). So, if you have 10MB of data, this will > be will stored in a file slightly larger than 10MB because I believe the > data is serialized in some form. This file is accessed upon page load and is > written to for the next page request. File I/O is generally pretty fast... > generally much faster than database I/O. > >> > >> In the database storage, you must run queries to pull the data > necessary. This requires a connection plus the time to query plus the time > to organize the data. If you have 10MB of data, then you still have to pull > all of that from the database, so I don't believe you're getting any speed > advantage. If you're application is running on multiple servers, then you'd > want to consider the database storage. IMO, only use the database (for > session storage) if it solves a problem that can be easily fixed otherwise > by using file-based session storage. > >> > >> Hope that helps, > >> ~Philip > >> > >> -- > >> http://lonestarlightandsound.com/ > > > > > > I apologize for posting not-complete data :-) > > The size of the data is, I believe, small. 1-2 words per array element or > number. No image or something like that is stored in $_SESSION. I believe > no more than few Kb. > > > > My concern is not only speed, than handling (as you said "time to query > plus the time to organize the data..."),as well as security. I read > Shiflett's article but it dates from 2004 and I believe some stuff are > changed too :-) > > > > As I said, I prefer working with $_SESSION instead storing data into > session table, but always wondered is that correct approach. > > Whatever session storage mechanism you use, you can continue to use > $_SESSION. The process Chris describes in his post replaces the engine that > loads and saves the contents of $_SESSION. You might want to read a lot more > about how sessions work before you consider customising the storage > mechanism. > > -Stuart > I don't see that the default file-based session storage as any less secure than another approach. If your session data is only several KB, then just use the default.... unless you have a specific reason not to... ~Philip
