What's is better for a members database?

Hi开发者_如何学Python and thanx for reading my post i am having a little trouble learning my database in mysql. Now i have it set up already but recently, but i had another person tell me my members table is slow and useless if i intend to have a lots of members!

I have looked it over a lot of times and did some google searches but i don't see anything wrong with it, maybe because i am new at it? can one of you sql experts look it over and tell me whats wrong with it please :)

--
-- Table structure for table `members`
--

CREATE TABLE IF NOT EXISTS `members` (
  `userid` int(9) unsigned NOT NULL AUTO_INCREMENT,
  `username` varchar(20) NOT NULL DEFAULT '',
  `password` longtext,
  `email` varchar(80) NOT NULL DEFAULT '',
  `gender` int(1) NOT NULL DEFAULT '0',
  `ipaddress` varchar(80) NOT NULL DEFAULT '',
  `joinedon` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `acctype` int(1) NOT NULL DEFAULT '0',
  `acclevel` int(1) NOT NULL DEFAULT '0',
  `birthdate` date DEFAULT NULL,
  `warnings` int(1) NOT NULL DEFAULT '0',
  `banned` int(1) NOT NULL DEFAULT '0',
  `enabled` int(1) NOT NULL DEFAULT '0',
  `online` int(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`userid`),
  UNIQUE KEY `username` (`username`),
  UNIQUE KEY `emailadd` (`emailadd`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=19 ;

--
-- Dumping data for table `members`
--

It's going to be a site for faqs/tips for games, i do expect to get lots of members at one point later on but i thought i would ask to make sure it's all ok, thanx again peace.

Did the other person explain why they think it is slow and useless?

Here's a few things that I think could be improved:

email should be longer - off the top of my head, 320 should be long enough for most email addresses, but you might want to look that up.

If the int(1) fields are simple on/off fields, then they could be tinyint(1) or bool instead.

As @cularis points out, the ipaddress field might not be the appropriate type. INT UNSIGNED is better than varchar for IPv4. You can use INET_ATON() and INET_NTOA() for conversion. See:

Best Field Type for IP address?
How to store IPv6-compatible address in a relational database

As @Delan Azabani points out, your password field is too long for the value you are storing. MD5 produces a 32 character string, so varchar(32) will be sufficient. You could switch to the more secure SHA2, and use the MySQL 'SHA2()' function.

Look into using the InnoDB database engine instead of MyISAM. It offers foreign key constraints, row-level locking and transactions, amongst other things. See Should you move from MyISAM to Innodb ?.

I don't think it's necessarily slow, but I did notice that among all other text fields where you used varchar, you used longtext for the password field. This seems like you are going to store the password in the database -- don't do this!

Always take a fixed-length cryptographic hash (using, for example, SHA-1 or SHA-2) of the user's password, and put that into the database. That way, if your database server is compromised, the users' passwords are not exposed.

Apart from what @Delan said, I noted that;

1. JoinedOn column defined as ON UPDATE CURRENT_TIMESTAMP. If you need to maintain only the date joined, you should not update the field when the records been updated.
2. IPAddress column is VARCHAR(80). If you store IPv4 type IP addresses, this will be too lengthy.
3. Empty string ('') as DEFAULT for NOT NULL columns. Not good if intention is to have a value (other than '') on the field.
4. Empty string ('') as DEFAULT for UNIQUE Fields. This contradicts the contraints enforced if your intention is to have a Unique Value (other than '').