I wound up inheriting a site which seems like it was originally designed to provide access to registered users then decided it wanted public access with the exception of specific restricted features. The access control is decent, however, what's boggling my mind is why anyone would add an entry to their database for each unique visitor.
The authentication code checks for the existence of the cookie and session and if it does not exist creates a limited user account and sets the cookie as such:
$session = md5(time() . "sitename" . $_SERVER['REMOTE_ADDR']);
setcookie("sitename",$session, time()+ 14 * 24 * 3600, "/",".sitename.com");
mysql_query("INSERT user(session,permissions) VALUES ($session, $permissions)");
$this->ActiveUser = mysql_insert_id();
There's a cron job on the server set to to run nightly that cleans up these sessions and reset the auto_increment value to the last registered user id + 1. While the clean-up script is good it seems to disregard the glaring design flaw that a flood of traffic (unique users) could make the INT value for the user id reach its mysql max value: 2147483647. Updating the user id to be large int would help, but only (theoretically) for so long. Also, if say there are 50 visitors between the last registered user and the first new registered user id of the day the auto_increment values in between will never be reused.
The site has good reporting metrics for visitors and members alike providing metrics on what items a user viewed, if it ended up in their shopping cart, and if they purchased that item by registering for an account.
I think the authentication function could be redesigned using SESSION variables for visitors and the shopping cart without touching the database and creating unused auto_increment values. The down side is that they would loose the custom reporting.
Obviously a trade off, but figured I'd post it here and see what thoughts were . Thanks!