php-general Digest 16 Aug 2011 08:14:20 -0000 Issue 7445
Topics (messages 314529 through 314538):
Re: Keeping session info in $_SESSION or in database?
314529 by: Stuart Dallas
314530 by: Philip Thompson
314531 by: LAMP
314532 by: Stuart Dallas
314533 by: Philip Thompson
314534 by: Ashley Sheridan
314535 by: Andrew Ballard
314537 by: Richard Quadling
Newbie question. What is the best structure of a php-app?
314536 by: Andreas
(Kinda sorta) PHP related: recovering lost passwords
314538 by: James Colannino
Administrivia:
To subscribe to the digest, e-mail:
php-general-digest-subscr...@lists.php.net
To unsubscribe from the digest, e-mail:
php-general-digest-unsubscr...@lists.php.net
To post to the list, e-mail:
php-gene...@lists.php.net
----------------------------------------------------------------------
--- Begin Message ---
On 15 Aug 2011, at 19:43, LAMP wrote:
> 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?
1) 30-50 array elements says nothing about the size of the data. That's like
saying you have 30-50 piece of paper and assuming that means they contain a lot
of text. If each array element is simply a number then 30-50 is not even close
to being big.
2) Size of data is never good reason why you'd switch your session storage from
files to a database. The data still needs to be read and unserialised at the
start of a request, and serialised and written back at the end. In fact, with
larger amounts of data you may find file-based storage to be faster.
-Stuart
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
Crap! I wish this list would have a reply-to list automatically....
---------- Forwarded message ----------
From: Philip Thompson <philthath...@gmail.com>
Date: Mon, Aug 15, 2011 at 2:11 PM
Subject: Re: [PHP] Keeping session info in $_SESSION or in database?
To: LAMP <l...@afan.net>
On Mon, Aug 15, 2011 at 1:43 PM, 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,
> 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/
--
http://lonestarlightandsound.com/
--- End Message ---
--- Begin Message ---
On Aug 15, 2011, at 2:11 PM, Philip Thompson wrote:
On Mon, Aug 15, 2011 at 1:43 PM, 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,
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.
Thanks,
LAMP
--- End Message ---
--- Begin Message ---
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 <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,
>> 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
--
Stuart Dallas
3ft9 Ltd
http://3ft9.com/
--- End Message ---
--- Begin Message ---
On Mon, Aug 15, 2011 at 2:36 PM, Stuart Dallas <stu...@3ft9.com> 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 <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,
> >> 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
--- End Message ---
--- Begin Message ---
> On Mon, 2011-08-15 at 14:12 -0500, Philip Thompson wrote:
> Crap! I wish this list would have a reply-to list automatically....
It does, just hit the reply to all or reply to list button on your email
client. I know Gmail has both these options, and the client I use
(Evolution) does and is available for a variety of different platforms.
--
Thanks,
Ash
http://www.ashleysheridan.co.uk
--- End Message ---
--- Begin Message ---
On Mon, Aug 15, 2011 at 4:33 PM, Ashley Sheridan
<a...@ashleysheridan.co.uk> wrote:
>
>
>> On Mon, 2011-08-15 at 14:12 -0500, Philip Thompson wrote:
>> Crap! I wish this list would have a reply-to list automatically....
>
> It does, just hit the reply to all or reply to list button on your email
> client. I know Gmail has both these options, and the client I use
> (Evolution) does and is available for a variety of different platforms.
>
I don't see a Reply-to-List in Gmail, and haven't seen it any any of
the other mail clients I have used either. Reply-All is a pretty
standard option, though.
Andrew
--- End Message ---
--- Begin Message ---
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,
> 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
--- End Message ---
--- Begin Message ---
Hi,
I'm fairly new to PHP but not to programming as such. Currently I sat up
XAMPP with xdebug, Netbeans and Eclipse to get a feeling.
I can write and run php-files but I am wondering how I should construct
a more complex application that runs over several pages between a login
and a logout.
How would I structure such an application so that it is possible to run
it in the debugger from the beginning?
E.g. as a simple example I may build an index.html that has a menue with
links to 3 php-files.
1) login.php
2) enter_data.php
3) list_data.php
as html-links within an ul-list.
The user should at first click on login where user/password gets entered
an a session starts.
Then the application comes back to index.html.
Now he might click 2) ...
Is it possible to run the whole application from the start on?
index.html is no php so xdebug won't process it and therefore the IDEs
may start index.html but can't show the stage where the page is just
waiting e.g. for a click on "login" and later branch for the other options.
Even if I write an index.php that shows the menue eventually the script
just dumps the html that'll wait for the following clicks.
Those following steps are far more likely in need to be debugged.
Is it neccessary to debug those subpages separately even though they
need prior steps like login.php that store some infos in a session or
cookie that later scripts need to rely on?
Can I somehow watch what is going on from the index.html on?
Until now I just found documentation that explains the php language.
Thats good too but I'd need to get an idea about the "web-app-thinking"
that consist of just pages where the designer has to hope that the user
stays within the applicationflow instead of clicking unexpectedly on the
back-button or just jumping off to some other site if he likes to.
In contrast to this desktop-apps seem to be less demanding because I
know where a user can navigate from a certain stage within the app and I
could step from program start to stop with the debugger if I feel the
need to.
Is there a tutorial that explains how to build consistent web-apps
beyond the details of php language?
regards...
--- End Message ---
--- Begin Message ---
Hi everyone,
I don't post all that often, so I hope my (mildly) off-topic question
won't be too unwelcome... Keep in mind that I'm still pretty new when
it comes to security, so what I propose may or may not sound incredibly
dumb (you have been warned! :-P)
I'm working on a project in PHP, a toy framework, and would really like
to be able to send someone their password should they ever forget it.
The only problem is that it's best not to store the actual password in
the database, or at least to store it unencrypted.
Security-wise, how would the following scenario work out for password
retrieval:
You ask the user to setup a "security question" when they create their
account. You use the string value of the answer to the question as a
cryptographic key, and encrypt the password with it. You also generate
a random string of characters, and encrypt it with the same key. You
store the encrypted password, along with both the encrypted and
unencrypted versions of the randomly generated string, in the database.
When the user goes to retrieve their password, they enter their security
question. The randomly generated string is then decrypted using the
answer as the key. If it matches the unencrypted version stored in the
database, you know you have the correct answer, and use it to decrypt
the user's password and send it to the email the user has setup for
their account.
James
--- End Message ---
