Let me clear up some confusion.  

PHP sessions are no more secure than cookies, in fact, PHP sessions only decide 
whether 
the user's browser allows cookies to save data, and if not, PHP creates all 
session data in 
GET strings appended to your links in order for sessions to work.  It would in 
theory be 
possible for a user to alter their cookie (and therefore, session) data or to 
send you bad 
data in a cookie or session, so this data still has to be validated before you 
use it on each 
page or else you may get unexpected results.

AJAX can speed up display of pages SOMETIMES, but as often, I have seen AJAX 
used 
improperly, which actually slowed down page loading speeds.  Basically, AJAX 
just uses 
javascript to submit form requests behind the scenes, as well as capture the 
result set 
from the query behind the scenes, and then AJAX shows that data on the webpage 
you've 
been looking at all along.

Database connections are indeed very expensive to the processor compared to 
queries, 
however, MySQL is lightning-fast, and we're only talking about fractions of a 
second here.  
What you don't want to be doing is creating a connection to the db for each and 
every 
query and then terminating the connection, only to open it again a few lines 
later in your 
code when you want to query the db again.  

Make one connection at the beginning of every webpage that uses the db, then 
close that 
connection at the end of the webpage.  If your webserver is serving up 
thousands of pages 
per minute, you can use connection pooling (web search the term), but I think 
you'll be 
fine without that.

Ken Krauss
http://www.kcwebdev.com





--- In [email protected], David Halliday <[EMAIL PROTECTED]> wrote:
>
> Thank you, Parag , for the reply.
> 
> As for option 3, AJAX, I have heard a lot about it but
> not have time to actually learn it yet.
> 
> Option 2, sessions, is more secure. Thank you for the
> information.  But the question remains : how big a
> variable can be and is it better to save the array of
> pulled data in a session variable RATHER THAN opening
> a database connection every time the page is loaded?
> 
> regards,
> 
> David
> 
> worth doing it through  sessions 
> --- Parag Bhavsar <[EMAIL PROTECTED]> wrote:
> 
> > Hi David,
> >    
> >    There are some ways to avoid the populating data
> > from database again and again.
> >      1. Cookies - if information that you are going
> > to display is not so important
> >      2. Session - Only Important information can be
> > stored in session as it is more secure.
> >     3. For Improving speed of display - Use Ajax.
> >    
> >   I hope by this information you can able to decide
> > what to use.
> >    
> >   Thanks.
> >    
> >   Regards,
> >    
> >   Parag Bhavsar
> > 
> > David Halliday <[EMAIL PROTECTED]> wrote:
> >           Hello
> > 
> > I have this html page which is loaded after a user
> > logs in. The variables on that page are populated
> > from
> > one or more rows of data which of course belongs to
> > the user in question. The user may click a link on
> > the page to change a password or email and when the
> > operation is completed the page reloads again.
> > 
> > Now the way I have been doing this is to pull an
> > array
> > of data from the database *every time* the user
> > loads
> > the page. I have recently read somewhere on the net
> > that "most of the time is spent in the actual
> > connection with the database .. the remaining
> > operations are relatively insignificant, time-wise."
> > 
> > 
> > Would it be safe on memory and overall performance
> > if
> > I stored the array as one session variable instead
> > of
> > several connections with the database?
> > 
> > Would that be a good idea even if the session
> > variable
> > is large? (several rows of values - about 50).
> > 
> > Would greatly appreciate an expert advice.
> > 
> > Regards,
> > 
> > David
> 
> 
> 
>       ___________________________________________________________
> Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
> now.
> http://uk.answers.yahoo.com/
>


Reply via email to