Best way to make a Admin Panel

[markman641]

I'm making someone a script and I've come to the point where I need to make them an admin panel for easy access. Basically, the script is a quiz site. I'm trying to figure out the best way to put an admin panel for it.

I currently have my mysql set up as the table being named "camp1" "camp2" "camp3" or whatever. Each campaign is a different set of questions. In the table camp1 i have the following rows: Question, answer1, answer2, answer3, answer4

In the admin panel, I'm trying to make it where the user can Add Questions (with answer set), Remove Questions (Delete the row, shouldn't be hard), and edit the question and answer set.

What would be a good way to do this? Please keep in mind the user does need to select which campaign they want to edit, but that is easily done. Could this all be done in one page, or should it be multiple pages?

[Redcoder]

If you use AJAX, which can be implemented easily if you use the JQuery functions or slightly more lengthy if you use the 'pure' Javascript XMLHttpRequest way.

There is no best way to make the Admin script. You can make just one script which has all the functions or multiple scripts. But with AJAX and Javascript, it can be one page to do it all. Add, delete, edit e.tc making doing the questions job smooth and .

[Old Pedant]

I currently have my mysql set up as the table being named "camp1" "camp2" "camp3" or whatever. Each campaign is a different set of questions. In the table camp1 i have the following rows: Question, answer1, answer2, answer3, answer4

Almost surely bad DB design. You should NEVER have multiple tables with identical structures and contents that differ only in who or what they belong to.

You should have *ONE* table with questions for all campaigns. Use a single field in that table to designate which campaign each question is for.

In the table camp1 i have the following rows: Question, answer1, answer2, answer3, answer4

No. You have the "following columns" or, better, "following fields". One "row" (better called "record") holds one instance each of those fields.

It's really a bad idea to talk about "rows" and "columns" in a database; it makes you think you are working with a spreadsheet, not a database. It's certainly not wrong to do so, but I think it's better to use "records" and "fields" to clearly distinguish a database table from a spreadsheet table. There *are* things you can do in spreadsheets that you can't do in databases and vice versa.

The very fact that you have multiple tables named "camp1", "camp2", etc., kind of confirms that you are thinking of spreadsheets, not databases.