At 11:31 PM -0400 7/9/09, D.M.Jackson wrote:
Hi,
OK, I did a count on the session.inc file and there appears to be 37
variables accessed through the $_SESSION object. By and large they all
appear to be scalar variables that contain a counter or a path or a boolean.
Nothing that looks like a big object. Mostly stuff like" MaxDisplayRecords,
DefaultDisplayRecords, Theme, DefaultTheme, CustomerId, RealName,
CustomerBranch, Module, UserStockLocation, PageSize, AccessLevel,
AttemptsCounter, Language, PageSecurityToken, DatabaseName...etc.
Initially, when you hit the index page the session.inc file is included.
From there, depending on what choices you make from the options displayed it
assembles a page by calling the a php file that calls the database if
needed, includes a header.inc file and a footer.inc file and builds the
appropriate html for the body and of course, includes the session.inc file.
My question is, assuming 37 variables of this type in the
session.inc file, at what level of concurrent user access do you consider
changing the way you do business here. Bare in mind that I don't comprehend
a whole lot about server and database clustering and big enterprise big iron
stuff like that. I'm just a guy trying to learn how to write decent php
code that I don't have to be embarassed of when I shift gears in a new
direction to add a marketable skill in my career development path.
Mark:
Without seeing/understanding the code, I would consider dividing the
"variables" into different groups -- those that are static (don't
change during a user visit) and those that change depending upon
*user* input.
For example, an admin might change a "static variable" OR a user
might set a "static variable" in their preferences, but once set,
then the variables really takes on the flavor of static rather than a
real variable -- if that makes sense. That's my rational for the
difference between a variable and a static variable, which is a
contradiction in terms I know, but true none the less.
Those data that are static I would place in a require_once() include
and load as needed.
Those data that change I would place in a table and use them as
needed via calls to the database.
Variables with names like "CustomerId" and "RealName" appear to be
values that change depending upon the customer. As such, then those
items should (IMO) be placed in a relational database and only the
"CustomerId" placed in a session and passed between pages. That way
any page requiring the "RealName" of the customer can be obtained by
a simple call to the database to pull the data associated with that
"CustomerId". That type of data IMO should not be held in sessions --
but only the index to it.
For example, let's say your script is for an employee to process a
customer's purchase. Once they have the customer ID, then all the
data associated with that customer can be obtained from a single call
to the database from a single session id instead of passing those
data between pages via sessions. Do you see how that works?
In any event, that's the way I would do it.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
