Structuring a database for membership details

This is my first post on these forums. I have been reading Sitepoint’s ‘PHP & MySQL Novice to Ninja’ by Kevin Yank (5th Ed, May 2012) and now I am trying to put it into practice. I want to build a website for displaying news photographs to a restricted audience of media professionals, who will hopefully go on to pay me for publishing my pictures. Initially I am trying to create a registration page that will collect information from my visitors (first name, last name, job title, organisation, country, landline, cellphone, email address, hashed password), and then a login page for members who have registered. Members will obviously need to be able to edit their entries if details subsequently change.

I have studied Kevin Yank’s example of the joke database that he creates in the book, but it doesn’t seem directly transferable to the kind of database I need to build, unless I am simply not understanding it correctly.

In terms of structuring the database and best practice, should I have 9 separate tables for each element of information that I am collecting and link for each individual using look-up tables, as Kevin does for his joke database? Alternatively would it be better to have just one table with 9 columns for each member?

Many thanks in anticipation of any answers to that question, and general advice about the way I’m starting out or experiences of Kevin’s manual.

no, in this case you need only one table, for your registered visitors

store the data in appropriate columns like VARCHARs

there should be no need for “lookup” tables, unless there is some element of data which has a limited set of valid values that you want to control

the closest example would be country code, but even here, i would not use a lookup table – just let them enter whatever they want