Question

• What is the most important data I should gather from a client for a basic e-commerce site ?

  These are some of the data that comes to mind mind separated by sections (this is not a table design just yet as it could be altogether or separated but will go into that later):

  • Login credentials:

    email, password
    

  • Secret question data:

    secret question, secret question answer (or other method)
    

  • Client data:

    name, last name, birthday, address, city, state,
    country, postal code, phone, cellphone
    

  From the above I might be missing something but would appreciate if you could point out any other beneficial data that I could collect for the registration schema.

  Should I also have a username and allow the user to pick which one he wants to use to login ? Does that bring any advantages ?

• What field type should I use that best describes each fields below ? Anything I have defined that I should change or consider ?

• Should I use more then one table ?
  • why ? when ? any gains other then organization ?
  • What about when I need to retrieve it with inner or left joins wouldn’t that be bad in a way ?

Here is an example of the design I was thinking as single table for now:

id int(X) PRIMARY auto increment
email varchar(X) UNIQUE
password_hash varchar(64)
password_salt varchar(6)
language tinyint(1)
time_offset varchar(5)
secret_question_id tinyint(3)
secret_question_answer varchar(X)
name varchar(X)
last_name varchar(X)
birthday datetime
address varchar(X)
address_complement(X)
city_id int(X)
city varchar(X)
state_id int(X)
state varchar(X)
country_id int(X)
postal_code int(X)
phone_regional_ext int(X)
phone int(X)
cellphone_regional_ext int(X)
cellphone int(X)
ts_register datetime
ts_last_update timestamp NULL on update CURRENT_TIMESTAMP
status tinyint(1)

Things marked with X I still need to check and see an acceptable size or correct field type.

As for state and state_id as well as city and city_id that is considering countries I don’t have that kinda of data available to allow the users to input it by themselves or select one available with in the system.

Answer 1

Security issues
Note that the secret question undermines your whole security system. because you are storing the secret answer AND the secret question in the clear.

I recommend not using it. Email a reset password to the confirmed email address instead.

If you must use the mistaken notion of the secret question (the answer to which is an easy google on the user’s Facebook page).
At least store the answer as:

answer_hash = SHA2(CONCAT(salt, lowercase(answer)),512)

Should I also have a username and allow the user to pick which one he wants to use to login ? Does that bring any advantages ?

• As a user I prefer the email address.
• It is unique, I can never remember my username, but the email address is easy.
• The email address does double duty as communication link to the user.
• If you must have the email address, adding a username is just extra effort with no benefits.
• If a username must be unique, you’re putting further burden on the user (nobody wants to be named snowwhite45875 because snowwhite 1..45874 are already taken)

•Should I use more then one table ? •why ? when ? any gains other then organization ?

I don’t think that’s needed, 1 table will do fine for now and it will simplify your database.
If you want to split off data later into 2 tables, you can use a view to combine the tables.

•What about when I need to retrieve it with inner or left joins wouldn’t that be bad in a way ?

Optional data is retrieved using a left-join.
Data that links 1-to-1 is retrieved using an inner join.

If you join on primary keys it will not take a huge amount of time, but it will still take time.