The examples you've seen so far have gotten your feet wet with sessions, but perhaps additional explanation is warranted for using sessions "in the wild," so to speak. The next few sections outline some examples of common session usage.
Working with Registered Users
Suppose that you've created an online community, or a portal, or some other type of application that users can "join." The process usually involves a registration form, where the user creates a username and password and completes an identification profile. From that point forward, each time a registered user logs in to the system, you can grab the user's identification information and store it in the user's session.
The items you decide to store in the user's session should be those items you can imagine using quite a bitand that would be inefficient to continually extract from the database. For example, suppose that you have created a portal in which users are assigned a certain level, such as administrator, registered user, anonymous guest, and so forth. Within your display modules, you would always want to check to verify that the user accessing the module has the proper permissions to do so. Thus, "user level" would be an example of a value stored in the user's session, so that the authentication script used in the display of the requested module only has to check a session variablethere would be no need to connect to, select, and query the database.
Working with User Preferences
If you were feeling adventurous in the design phase of a user-based application, you might have built a system in which registered users could set specific preferences that would affect the way they viewed your site. For example, you may allow your users to select from a predetermined color scheme, font type and size, and so forth. Or, you may allow users to turn "off" (or "on") the visibility of certain content groupings.
Each of those functional elements could be stored in a session. When the user logs in, the application would load all relevant values into the user's session and would react accordingly for each subsequently requested page. Should the user decide to change her preferences, she could do so while logged inyou could even prepopulate a "preferences" form based on the items stored in the session rather than going back to the database to retrieve them. If the user changes any preferences while she is logged in, simply replace the value stored in the $_SESSION superglobal with the new selectionno need to force the user to log out and then log back in again.