#native_company# #native_desc#

Best practices: Sessions

By Paul Booker
on August 19, 2002

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”.