views:

50

answers:

2

I am fairly new to building sites with PHP and MySQL but am trying to achieve the following:

During an online enrollment process, a promoter is able to enroll up to 20 'fighters' for medical testing services. Each fighter's information is stored in SESSION as $_SESSION['FnumAttr'] where num is the number and Attr is the attribute being defined (first name, last name, etc). At the end of the enrollment, I need ALL of the data entered stored in a MySQL DB and eventually sent on elsewhere. A manager can enroll from 1 to 20 fighters at a time and any thing less than 20 will just not have data (null) within its cell.

I am currently building out the DB within MySQL but if I have to enter 20 attributes for 20 different fighters this may take all day (not to mention the "INSERT INTO" call I'll have to make at the end of all this).

Is there a way to create these fields more quickly than going line by line and adding: F4_Firstname, type text, length, allow null, etc..?

A: 

You could use phpMyAdmin

msakr
@mahmoudsakr - I already was using phpMyAdmin - now have moved onto Navicat because it is much faster but will still take me an hour or more to enter 400+ fields into a database.
JM4
Do all the data have to be meaningful?
msakr
can you please elaborate - I am not sure what you are asking. If the data is entered the site, it is meaningful to us, yes. We cannot determine whether a manager will enroll 3 or 19 of his fighters/employees so we have to build the DB with over 400 fields to collect all possible information and store it in unique fields because this information is then passed along elsewhere
JM4
+1  A: 

This looks like a one-to-many relationship. Instead of having 20 columns create a new table called "fighters" that contains a fighter id, parent_table_id, and the information about the fighter.

When you need the fighter information you join the fighter table with the parent table on parent_table_id.

To load this new table just loop through your original array and issue an insert statement for any entries you find that are not null. If you make the new table's PK a concatenation between fighter_id and parent_table_id then you can use 'num' from your input data directly as fighter_id.

bot403
@bot403 - I am not sure I follow the logic here. What information is then contained in the parent table that makes the 'fighers' table any different? The DB as is will have over 400 columns (because F1FirstName, F19FederationNumber are all unique). I will not be pulling this information as much as the importance of simply storing it. I am only trying to figure out how to replicate column names in rapid succession without having to type all day
JM4
You should not be replicating column names. You need to read up on normalization of relational schemas.
duffymo
@duffymo - Thank you for the suggestion. I thought I was somewhat familiar normalization and reviewed the following (http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html) but don't see how this applies based on the example I have given.The only relation is fighter to manager but this information is almost irrelevant to me until later in the process. In either case, I have to store all fighters in a database which would result in several hundred columns, no? I didnt previously mention but a fighter is also able to enroll themselves and therefore would not have a 'parent'
JM4
It's possible to add a row to the Fighter table when they register and add the foreign key relationship to Manager when it's appropriate in your use case. It applies more than ever, in my view.
duffymo
Duffymo - I am not sure how this relates however to a registration. My goal is to have each record (each row) represent a registration. ALL of the information from a single registration will be passed in a csv file to the medical offices for storage so breaking the tables out doesn't seem feasible for what I am trying to do. Perhaps I am looking at it the wrong way?
JM4