One of the best ways to implement the database storage of PHP session data is via the overriding session handlers built in to PHP. PHP has functions built in to allow you to override the default file based session handlers.

These functions all use PHP’s normal ways of handling session persistence between the client and the server (by default, via the use of a session ID cookie).

In other words, it utilises the same PHPSESSID cookie that the default file based session storage uses. When using functions that override the session handlers, the first parameter for several of these function is the session id. Upon overriding the functions, PHP will automatically pass the session ID (pulled from the PHPSESSID cookie) to these functions.

The code linked to below can be ‘required’ (require “session_start.php”) as a drop in replacement for the default PHP session_start() function. This utilises database access to store and retrieve session information. Note that due to the very early point in which PHP processes session handler overrides, objects are not available for use, hence the use of old style ‘mysql’ instead of OO based ‘mysqli’ (if you find a way around this, I’d be very interested in hearing about it).

Download ‘session_start.php’ for database storage of session data

Required Table Structure SQL

In terms of performance, there is limited degradation to using database stored sessions with most small to mid range sites, based on my experience and observation. However, larger sites may possiblynotice degradation. In such circumstances, this would likely be related to the MySQL database server load and/or high levels of IO on the MySQL server. Issues of database server load can be mitigated via one or more of the following:

• Separation of the site database and the session storage database (seperating each to their own server if necessary)
• File based caching of session information on the web server system (using standard PHP file reading/writing functions, ensuring that the file cache is updated whenever there are changes to the session information in the database store)
• In memory caching (similar to file based caching, but utilising a key to value storage engine which runs in RAM, providing very fast (atomic) access to data) – using a system such as memcached - http://memcached.org/

For building reasonable size websites in which portability is important, the need to load balance is highly probably in the future and where development time permits, I’d  personal recommend database storage for session information, due to the higher level of flexibility this set-up offers.

I hope this information helps anyone looking to make a PHP powered site just that little bit more portable by placing their users’ session data in a database.

The latest MySQL documentation (5.5) discretly mentions the fact these constraints are unfortunately not supported.

• The CONSTRAINT_TYPE value can be UNIQUE, PRIMARY KEY, or FOREIGN KEY.
• The UNIQUE and PRIMARY KEY information is about the same as what you get from the Key_name field in the output from SHOW INDEX when the Non_unique field is 0.
• The CONSTRAINT_TYPE column can contain one of these values: UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK. This is a CHAR (not ENUM) column. The CHECK value is not available until we support CHECK.

Take special note of the final line I’ve emboldened. This is quite a shame that this constraint type is not fully supported yet.

Apologies to readers for the implication that this was functional in my previous post, and thanks to the poster of this comment for noticing the discrepancy.

Check constraints, of course, function fine in many other DBMSs, and to that end, the original post on SQL check constraints is still relevant, but sadly not if you are worked with MySQL.

You can create a table with a check constraint in MySQL as follows. The check in this example disallows values of the ‘P_Id’ field from falling outside of the condition ‘P_Id>0′. In other words, the ‘P_Id’ field’s values must almost be greater than zero in order for the data to be accepted into the table by the database management system (DBMS).

CREATE TABLE Persons
(
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255),
CHECK (P_Id>0)
)

You are probably wondering how to add a constraint to an existing database table. This is quite easy, and uses an ‘ALTER TABLE’ SQL query. See the following example for how to add a check constraint to one of your existing database tables.

ALTER TABLE Persons
ADD CHECK (P_Id>0)

For more information, there are other highly useful example queries relating to SQL check constraints at the relevant SQL check constraint article on W3schools.