It is the intention of this article to discuss and generate further debate surrounding best practices in developing database driven, session orientated dynamic websites and to present some adopted styles and conventions. The ideas and approaches that are developed here could be realised with almost any combination of server side scripting language and relational database.

Sessions and relational databases both offer the opportunity of storing information server side. Sessions can help to maintain state while you navigate an internet website and relational databases offer a medium for the permanent storage of information in a logical and consistent manner which allows for structured queries to be carried out against that stored information.

During the design process the dilemmas that are often encountered are deciding how information should be stored in a database and what information should be registered to the session.

What I would like to demonstrate now is a framework of cooperation between relational databases and sessions which is both aesthetically appealing as well as productive this will be done by examining features of a secure website.

First of all I would like to discuss in simple terms what it means for a table to be normalised. A table is considered normalised if information is organised logically without inconsistencies and there is minimal redundancy an example will help to demonstrate.

Consider the following simple normalised table called security, this table stores sensitive information and is queried against to gain authorisation to a secure website.

   username     password     access_level  screen_name   security_id


   rstallman     r5y8jv5f8      U            richard         1

   billgates     8yc2d42f5      X            bill            2

   linustorvalds h89x35f56      P            linus           3

Notice that this security table encapsulates all that is security related there is no redundancy, that is no unnecessary repetition and if you had to update a username or a password you have only to make a single change somewhere. This is normalisation.Also note that all records here in the security table have a unique identifier called security_id this in a important field called a "primary key".