kiq wrote:
Length/values: The max length of each field (if you are encrypting the password you need to allow for this)
An explanation is in order, I feel. If you're 'encrypting' the password, i.e. storing a hash of the cleartext password (which is standard practice) then it is a Good Idea to define the field length based on the output of the hash, i.e. 32 characters for MD5, 40 characters for SHA1, etc. Depending on the method used, and whether you store a salt value
appended to the hash will define your field length (vs. a salt within the hash itself).
As a default method for now, I would use CHAR(40) as the `password` field, and store a SHA1 hashed value of the cleartext password. The SHA1 hash mechanism is a standard within PHP and MySQL, and you can easily find a
JavaScript API. In addition to this. I strongly recommend
using a SALT within the hash value. Once you understand the methods involved, you might want to move up to something like
this or simply use a stronger hash mechanism. I believe SHA1 will be going the way of MD5 soon, but it should be fine for now...
FYI, defining a field as CHAR when you know the finite length of the field is good practice. Using VARCHAR and allowing some extra room is good practice when you are uncertain of the final string length, e.g. when a username field can be anything from 3 to 30 characters, define as VARCHAR(30).
Primary: Tick this box for username, it will prevent duplicate usernames (you could do with some scripting on the signup page to inform if the name already exists)
I strongly recommend NOT using this method, instead use a 'UNIQUE' index on the username field, so that only one of each username can be allowed. When you register a user, performing the INSERT will fail, allowing you to give feedback to the user that that particular username has already been taken. At the very least, a standard INDEX should be used, not PRIMARY. A PRIMARY KEY field should be an INT type field and be set auto_increment to give each user a unique PK value to reference in other tables.
Note I still advise reading all the material I posted initially, since it will give you a much better understanding of how MySQL works, how to define fields, create a table, etc. I started out with the 'mysql' command line and it's hard for me to use anything else, although I do use phpMyAdmin on occasion to perform simple tasks, or when a client doesn't have SSH access to their server. You can get yourself into hot water (and simply make alot of bad choices) by letting phpMyAdmin do everything for you.