Storing Username in $_SESSION
Moderator: General Moderators
Storing Username in $_SESSION
Is it ok to store username in $_SESSION (the username is used in login)? Or would it be better for me to add an extra ID field in my user table and store ID instead?
Is your username the unique id for your table? You should always have an numeric index. It will make for much more efficient queries.
As for your question; it doesn't really matter. I would store the ID so I can do quick inserts such as:
As for your question; it doesn't really matter. I would store the ID so I can do quick inserts such as:
Code: Select all
$qry = "Insert into tbl_visit(pgid,userid) values('$pg','".$_SESSION['VISID']."')";I have never used indexes before, do they make query processing more efficient on DB level? I think indexes are used by the DB on its own (that is, DBMS decides whether it should use some index(es) or not), so since it seemed to be a bit of DB's bussiness I didn't put much priority on those and haven't used them yet. 
Btw, I remember that poorly set indexes in fact may make query proessing slower.
Btw, I remember that poorly set indexes in fact may make query proessing slower.
Poorly set indexes can make your query slower, that is why I said you shouldn't use the username as an index.
Think about the following two queries:
OR:
In this example with over 5k records which query would be more efficient?
I recomend researching database normalization.
Think about the following two queries:
Code: Select all
UPDATE myTable set last_login = now() where username = 'hereismyusernamelookylooky@somedomainname.com'Code: Select all
UPDATE myTable set last_login = now() where userid= 5001I recomend researching database normalization.
Set your index as the primary key.
Code: Select all
CREATE TABLE `tblpagehit` (
`id` int(11) unsigned NOT NULL auto_increment,
`visitor_id` int(11) default NULL,
`pg_id` int(11) default NULL,
`tmstamp` timestamp(14) NOT NULL,
PRIMARY KEY (`id`)
)The difference between those two queries, assuming both are indexed (and you can index text fields) is miniscule to nothing. There is no reason to promote integer surrogate keys over natural keys when a suitable natural key exists.hawleyjr wrote:Poorly set indexes can make your query slower, that is why I said you shouldn't use the username as an index.![]()
Think about the following two queries:
OR:Code: Select all
UPDATE myTable set last_login = now() where username = 'hereismyusernamelookylooky@somedomainname.com'
In this example with over 5k records which query would be more efficient?Code: Select all
UPDATE myTable set last_login = now() where userid= 5001
I recomend researching database normalization.
Well as I told, username is unique and set as primary key. The table itself only contains 3 fields: username (unique), password hash, and 'salt' (random string used in hasing). So basically both password hash and username fields are always unique, but since username is often shorter, I used it as primary key.