How To Save the State of Current Work? - php

I am working on a site that has tests users can take. I have a test area set up with 100 questions on each subject. If a user is taking a test, I want them to be able to save the work they have already done and when they return I want them to be able to continue the work from where they left. The questions being answer are multiple choice questions and they answer them by selecting the radio button and each radio button has a value of A, B, C, D, or E. I am using PHP and MySQL for my programming and database storage.
Would I need a table for each test and have 100 column names such as 1,2,3,4,5 all the way up to one hundred and when the user saves their work it will store the questions they have completed in the database? Is this a good method or is their another way of doing this?

Have a table for 'users' and a table for 'questions'.
Have another table, 'answers', with a foreign key to 'questions', a foreign key to 'users' and a column called 'answer'.
When the user answers a question, insert a record into the 'answers' table with the user id, the question id and the answer they provided.
If they have not yet answered the question, then there will not be a record in this table.

This is what I've come up with for a first Draft.
User
--------
UserId
UserName
Test
-------
TestId
TestName
TestQuestions
----------------
QuestionId
TestId
QuestionName
QuestionChoices
----------------
ChoiceId
QuestionId
Choice
UserTestAnswers
-----------
UserId
ChoiceId

Related

Dealing with permissions with MYSQL and PHP [duplicate]

This question already has answers here:
Many-to-many relationships examples
(5 answers)
Closed last year.
I'm doing a project for a music school and I have a table for students, a table for courses available and I was creating the table for teachers. My question is, how can i manage to "link" a teacher to a certain or more than one course, so that when the teacher logs in the admin page, he can only update and add information to the students that belong to the course/s that he is teaching.
My first thought was that I should have a field in the teachers table that could only contain values from the courseID (for example, if i want to register a guitar teacher and the ID of the guitar course is 3, i should have a field in the teachers table named teacher_course_id which would have the value 3).I also thought about having more than one teacher for a course, and if so, how can I give permissions to one teacher only (the teacher of that student) and not all the teachers from that especific course?
I don't really need the code for anything, I just wanted a a brief explanation on how could I do it. If I wasn't clear enough I can give more details in the comments
You need one more table for relation between teachers and courses, smth like that:
course
id
title
...
teacher
id
name
...
teacher_course
course_id
teacher_id
can_edit 0/1
...
You can create table with fields teacher_id, course_id with Primary Key (teacher_id, course_id)

i want a array which will be going to store the login user id with the exisiting id's

Updating the array without updating the existing record in it.
I am having a users table and course table. In course table i have
user_id and i want this user_id column data to be in array. So i
could define that this course has been taken by how many users.
I had Already tried it bu using insert method but it's not working and here the problem is we have update as well as create. So i am confused about how to get rid out of it.
For this how to update the array without updating existing id's in
array.
Thanks in Advance!!
and i want this user_id column data to be in array
Don't do that. You'll only be making things more difficult for yourself. The problem you're currently experiencing and asking about is just the tip of the iceberg.
Instead, create another table which has a foreign key to the users and a foreign key to the courses. Maybe call it something like usercourses:
usercourses
--------------------
id | INT PK AUTOINCREMENT
user_id | INT FK
course_id | INT FK
Conceptually, each record in that table represents an association between a users and a course. Each association is trackable and editable independently. This is called a "many to many relationship" between users and course.
As the complexity of the data grows, in cases like this the association itself can easily become its own entity. For example, in the domain of Students and Courses consider an entity called a Registration. It is the association between a Student and a Course, but also carries its own business data. The dates of registration, the student's grade perhaps, etc. Storing all of this in your array and stuffing it into a single string field would be problematic to say the least.

Correct MySQL structure for storing user-based data

So I have a question, I'm hoping it isn't too subjective.
I have a blog-style website, so on the homepage articles are loaded alongside the date published, the user that posted it, etc. Basic data like this.
I store it in MySQL like so:
article_id username date content etc.
1 user1 2015-05-14 01:35:14 my content a
2 user2 2015-05-16 02:33:15 my content b
This way, I can display it using one query, where I retrieve the username, date, content, etc.
My question is. I want to allow users the option to change their username. There are two options I see for this.
Either I continue storing data as I do now, and manually update tables like this with user-related data to the new username. Or I store data by a user_id rather than username, and have an extra query for each article loaded to get the associated username from another user table.
Which is the correct approach?
I ask this because I assume there's a recommended practice for this situation? Is it normal to store data by username and update it, or to store by id to avoid having to do this - but at the cost of the overhead when querying data. I'm guessing it's possible to display the username for id-based data in just one query, but that would still take significantly longer?
Depends. Do you see there is a 1:1 relationship with Article:User if yes, then storing in a single table will probably suffice but generally an user will publish multiple articles which will make it a 1:* relationship and in which case you should create a separate table for UserDetailsd and have user_id as FOREIGN KEY in Article table probably.
You should create a users table, store user_id which would be incremental and a user_name. When showing the user name in your app, join to the users table and show the name from that table and it will always be current. This is the best practice if you wish to allow user name changes. Updating all usernames it the articles table is not recommended. This will also allow you to store other user related information such as email, join date, etc... without having to keep all that in the articles table.
Create a seperate table with all user-related information and alter your current table, so only content and article related stuff is included. That's what I'd suggest you
Make a separate table for users something like:
-------------------
user_id | user_name
-------------------
Where user_id should be PK.
And another table, lets say article should look like:
-----------------------------------------------
arcticle_id | date | content | etc. | user_id
-----------------------------------------------
Where article_id could be a PK and user_id would be the FK from users table, making a relationship which could be used in other tables as well.
You can create a table for users, and use a foreign key on field username, specifying the behavior on updates. Is something like this:
alter table posts add constraint fk_post_user foreign key (username) references users (name) on update cascade;
In this way, when you update a row on table users, all user names on table posts will be updated too.

PHP Link user table to another table

Hi I am in the process of making a website that includes a user registration system for my final year of high school major project. The website stores driving logs for learner drivers. I'm kind of confused as to how I should desgin the database. I have a users table which stores the personal information of each user of the site. However, I would like the user to be able to insert information into another table which would be their "logbook" and this to be displayed on the my account page. Do I need to create a table within the database for each user or is there a way of connecting the tables so that i do not have to.
You do not need to create a table for each user. Instead, add a column in your "logbook" table which will contain and refer to the "id" of the user it's tracking. This will likely be the primary key of your "users" table. Then, to get the logs for a specific user, you would query the logbook table for rows only with at specific user ID.
Furthermore, in a more sophisticated setup, you can add constraints to link the two columns. See http://dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
U will not need table for each user...
Just one table will help u out...
The other table where u want to store user logs should only have reference to user I'd that u have created in users table..
Primary and foreign key - relational table concepts
For eg:
Let ur user has
1.userid
2.first name
3.lastname.... And other colums
Then ur userlogbook wala table should have
1.logid
2.userid
3.other columns...
Hope u got it..
You only need 1 table for the users, each user will be a row inside that table.
As you see in this table below, you need a way to be able to track which logbook record belongs to which user. That's done by storing the users ID (or any unique identifier, usually the primary key) to know exactly which user created the record.
-------------- -----------------
| User Table | | Logbook Table |
------------------------- -----------------------------------
| id | name | ...etc... | | id | user_id | date | ...etc... |
------------------------- -----------------------------------
| |
|_____________________________________|
I don't know how your system works, but I assume you know when a user is logged in right? Probably store their id in a session yeah? Well when you're inserting the logbook record, all you need to do is parse through their user ID in addition:
INSERT INTO logbook (id, user_id, .....) VALUES (NULL, $THE_USER_ID_FROM_SESSION, .....)
The above is pseudo code, you'd need to sanitize the input and actually assign the user id to a variable.
Now for fetching the user-specific information, all you need to do is add a simple WHERE clause:
SELECT id,column_1,column_2,... FROM logbook WHERE `user_id` = $THE_USER_ID_FROM_SESSION
The above is pseudo code, you'd need to sanitize the input and actually assign the user id to a variable.
There are a few questions I have, how much reading/writing are you going to be doing to the table? How are your tables set up?

Maintain many level hierarchy of tables in database

I have to maintain the data of friend list of friends who liked a particular category post. And this may be at any level. For eg.
if a friend of A who is B like a wanted post. then I ll maintain the record of A’s friends and B’s friend. Basically my requirement is
If user visit my product site I have to tell him/her that you're following friend already visited the same and they actually recommend you to use this and to build confidence that you are on the right way as your friends are also using it. I also want to suggest A that C who is the friend to B is using this product since this time and C suggest to many for using it.
I know this logic is already implemented in good sites.
I am just a starter. So pls suggest me the database for backend and required things for frontend.
Specially this question is to maintain the record on database. So I am asking for the database what should I use not how should I implement that would be next step.
As I am planning to use Graph database for it. In graph either bigdata or Neo4j.
Your ideas are most welcome and will be appreciated. Thanks
I hope my logic may takes you few steps forward
Initially we have to maintain the mutual friends records
foe example
id mut_id
1 2,3,4
Here 2,3,4 are your friends
next we need to maintain the records who has purchased/visited
prod_id buy_id
1 2,1
Now suppose 3 id wants to buy or visit site then we can show that your friend already visited or buyed product
Friends' relations is a classical many-to-many scheme. You need two tables to implement this:
1. A table with personal data, such as name, email etc. (could be more complex like person-properties relation)
2. A table with friends' retaionships data, usually it contains ID pairs of friends that relation is representing and some data about relation itself, such as category (friend/family/classmate etc) , level of affinity (if >0 it means positive relation, <0 negative such as enemies) and so on. Assume first ID is a person this relation belongs to (and can be maintained by), second ID is a person this relation applies to. Usually such kind of tables is constrained to pair of IDs to be unique, so nobody will be able to add same person as a friend twice
Here is some sample:
CREATE TABLE person
(
id INT NOT NULL AUTO_INCREMENT,
name VARCHAR(255),
email VARCHAR(255),
PRIMARY KEY (person_id)
);
CREATE TABLE relationship
(
id_person INT NOT NULL REFERENCES person(id),
id_person_related INT NOT NULL REFERENCES person(id),
id_category INT REFERENCES relcategories(id),
affinity INT,
PRIMARY KEY (id_person, id_person_related)
);
Note that affinity and id_category fiels are optional and last one requires table relcategories with INT id field to be create first
Visits of one friend to another can also be stored in relationship in a separate field

Categories