I'm currently building a service in which students can log in and read messages written by teachers/admins, download files and check their grades.
Problem: I have no idea how to input their grades and how to display them.
I'll try my best to describe what I want to do.
Teacher (Inputs Grades)
Student (Display Grades)
I already have these tables on my MySQL databse and i'm using PHP + Boostrap.
+-------------------------+
| Tables_in_portal |
+-------------------------+
| Messages |
| Students |
| Admins |
| Subject |
| Teachers |
| Classes |
+-------------------------+
You can build a teacher panel page, give teachers' their username and password and let the teachers enter grades for each student and then upload using a form. This will automatically add grades in each students' column in the grades table in MySQl which can be seen by students when they login from their portal.
And don't expect anyone to write the whole code for you here.
Related
I made a firm to add a user to my database now I want to have two tables. One table keeps track of the languages the user knows and the other table the design software the user uses.
Would I create 3 tables (profile, languages, software) each with an I'd field and when I add a user add a row to each table?
As you begin to add several many-to-many relationships, you need more tables to 'link' the information together. Here's how I would tackle the problem:
Note The IDs should all be unique indexed columns. Consider using AUTO_INCREMENT.
Table 1: Contains user's profile information
| ProfileID |UserInfo |
|=======================|
| 0 | Info |
|-----------------------|
| 1 | Info2 |
|-----------------------|
Table 2: Stores the possible languages
|LanguageID |LanguageName|
|========================|
| 50 | Python |
|------------------------|
| 51 | Java |
|------------------------|
and so on...
Table 3: Stores the Profile links to the languages
|ProfileID |LanguageID |
|========================|
| 0 | 50 |
|------------------------|
| 0 | 51 |
|------------------------|
| 1 | 50 |
|------------------------|
Every time you wanted to add a language to a user's profile, you'd create an entry in this table.
You would add two more tables for the software a user knows. One table for all the possible types of software, and another to store the links.
When you want to retrieve the information, you would do an operation such as the one below:
SELECT * FROM Table3
LEFT JOIN Table2
ON Table3.LanguageID = Table2.LanguageID
WHERE ProfileID = [TheProfileIDToSearch]
This structure uses JOIN to link tables together to return information from several tables at once. Here is a W3Schools quick explanation about SQL JOINS.
I am trying to design a database for the known 6/49 lottery game. But I am confused about designing. First thing came up my mind is something like that:
Table Users:
ID | Name | Age | mail | username | password | balance | etc. |
Table Coupons :
ID | Date | Draw Date | Chose 1..6 | isWinner | owner username | earning | Cost |
Is that enough? Or I really want to hear new ideas. For example, after a drawing, I am going to enter results to the system. Then system has to check all the coupons which belong to relevant draw date.
However, wouldn't it be too much load if there are hundreds of thousands coupons of this particular draw date? What is the best desing for this system? Or wouldn't it be to much load when a user tries to list the coupons that s/he has played in his/her account page?
And I have to say that, I am very junior about database designing.
I am currently developing a Student Information System that is going to be used by educational group to provide students & teachers a portal.
I am using Laravel4 which has a good authentication driver built in but can use only one table for authentication. I am unable to figure out how to authenticate them because I have users in multiple tables. Example :
SchoolOne_students
SchoolOne_teachers
SchoolTwo_students
SchoolTwo_teachers
and so on....
A significantly better way, rather than multiple users tables, would be to link each user to their school and status (teacher or student). You certainly can twist Laravel into doing what you want, but in order to prevent conflicts between the four different user types, you'll probably end up having to rewrite a large part of the entire authentication package.
What I would do is, in your users table, have an ENUM column, with the options student and teacher. Then, have an integer column, school_id (with a separate table for school data, if needed). This will allow much more flexibility, and when your design requirements change (yes, they will change), you'll be able to take them in stride.
Using this method, you should not have to modify any of Laravel's own code.
if all the tables have identical schemas, you could create a view that does a UNION of all the tables and then use that view as your Laravel auth table. I am not saying this is an ideal solution, but if you have restrictions on altering the existing tables and must use them as is, this could work.
The view would not be update-able (I don't believe so, at least) so adding or updating users would require specific add/update code, but for Auth, this may do the trick.
CREATE VIEW users_combined_view
AS
SELECT id, username, password
FROM schoolOne_students
UNION
SELECT id, username, password
FROM schoolOne_teachers
UNION
...
note - this method would be somewhat useless (ok, totally useless) if username was not unique across the tables
A good database design is scalable.
This is particularly a bad idea:
SchoolOne_students
SchoolOne_teachers
SchoolTwo_students
SchoolTwo_teachers and so on...
There should be only one table for all the users, in your case for students.
There should be another table for Schools where all the school information will be stored.
Then you should join the students table with schools table by adding a school_id field to the schools table where the school_id will be stored for the corresponding students row.
===Students Table===
+-----------------------------------------
+ id | name |school_id | ... | ... |
+----+--------+----------+-----------+----
+ 1 |Student1| 5 | ... | ... |
+----+--------+----------+-----------+----
+ 2 |Student1| 3 | ... | ... |
===Schools Table===
+-----------------------------------------
+ id | name | ... | ... | ... |
+----+--------+----------+-----------+----
+ 3 |School 3| ... | ... | ... |
+----+--------+----------+-----------+----
+ 5 |School 5| ... | ... | ... |
+----+--------+----------+-----------+----
This way you can add as many schools as you may want and students for them
I hope this will help
I am developing a website which will collect and store information for users.
I need to create a table specific to each individual user on registration to store the information they are searching for using the website. The table created will be named after the newly registered user's username.
Then when the user is logged in and runs the search, the data collected will be stored in a database using a MySQL insert query where the table name is a variable containing the logged-in user's username which will also be the table name.
I am an amateur developer and have searched everywhere to try and find a solution but I cannot seem to find anything evenly remotely similar to my problem.
Thank you in advance for any help!
Creating tables on the fly is more trouble than it's worth and very much swimming against the tide with any SQL database.
The reason you haven't found any docs about the approach you mention is because this problem is generally (almost without exception) solved best by having all the data in one or more tables, and including a column to specify which entity (user) the row is associated with. In your case, this might be an email address, or a username, or just a sequential number.
E.g.
| user_id | email | first_name | last_name | fave_color |
- - - - - -
| 1 | "a#b.c" | "anton" | "aardvark" | "red" |
| 2 | "b#c.d" | "miles" | "o'brien" | "infrared" |
| ... | | | | |
First take name from user like:
$fullname="$fname"."_"."$lname";
Then, write a query like this to create a table of that name
$sql="CREATE TABLE $fullname(ALL THE COLLUMNS YOU WANT TO CREATE)";
$result1=mysql_query($sql, $db_link);
this query is from my project. Works fine in wampserver.
I have one login form and three groups of users who can login: client, member, admin. All users share some common attributes, like username, password, active.
Most of the other fields are different for the respective group, with the table member having up to 30 fields.
This is the reason I would rather not have one large user table with all the needed fields, but separate the group related fields to different tables.
I would then have following tables:
------------------
| tbl_user |
|----------------|
| id |
| username |
| password |
| active |
------------------
------------------
| tbl_client |
|----------------|
| id |
| pid |
| company |
| address |
| projects |
| ... |
------------------
... same with tbl_member and tbl_admin.
But after the login, how can I select the additional fields from either tbl_client, tbl_member and tbl_admin?
I could use a group field in tbl_user and use the group table name as the value. But that doesn't seem very professional ;)
Any other ideas?
I don't know why you say "it doesn't seem professional". You're separating the user data role from the user authentication information as you should. There's nothing wrong with what you suggested and I would recommend it...
I would suggest adding another column in tbl_user that states what type of account it is. e.g. admin, member, client, that way you can direct them to whatever you need after they have logged in, and you can pull their information.
You could do an outter join on all three tables.
This will return results of all three tables, two of which will have null results (as they don't exist). This is less efficient as you are joining four tables (user, member, client, admin), then adding an additional field to specificy which group the member is a part of, and querying only that table with some logic.
What you suggested is a perfectly acceptable solution - tbl_user needs to identify the user type in some way, somehow. You could swap out the string for an id, if that may be easier to work with. After you determine the user type, you can then simply join with whichever detail table is applicable, or query the detail table directly.