Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 3 of 3
Thread: Best way to make a Admin Panel
10-07-2012, 02:21 AM #1
- Join Date
- Jul 2011
- Thanked 1 Time in 1 Post
Best way to make a Admin Panel
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?
10-15-2012, 03:12 PM #2
10-15-2012, 08:31 PM #3
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.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
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.
No. You have the "following columns" or, better, "following fields". One "row" (better called "record") holds one instance each of those fields.In the table camp1 i have the following rows: Question, answer1, answer2, answer3, answer4
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.
An optimist sees the glass as half full.
A pessimist sees the glass as half empty.
A realist drinks it no matter how much there is.