i am creating a marks management system using php & mysqlwhere the concerned faculty will be able to login and enter the marks of the students. i can go with a simple table but the problem is there are 288 different subjects for which marks must be entered. So creating a mysql table with so many subjects does not look good for me. please suggest me the best way to manage user permissions so that only the corresponding faculty will be able to enter marks
This is a fairly big and hairy problem; you do know that, right? It is good you're not regarding security as an after-thought, but I don't think it's security you're asking about.
I spent some time developing an academic management system a few years ago. Some of the design required was fairly involved. As well as subjects and students, we quickly found we needed a class structure so we could say this student was in this subject this term, but wasn't next term. And to say that this teacher taught this class this subject this term, but another teacher taught this other class the same subject this term.
That also meant we had to keep some information about when classes were, which turned into a timetable mechanism. (I won't go into that, though, as it was very involved.) And then we had to keep multiple sorts of marks for a student in a class, which created multiple task types, only one of which was end-of-term exams.
Finally, we abstracted our students and teachers into generic contacts. This allowed a permission system to generalise for editing objects they "owned". It also let us support advanced concepts like a former student returning to teach. And for all contacts to login in various capacities.
Table <Subjects>
List item
SubjectId
SubjectName
SubjectTeacher
.
.
Table <Marks>
SubjectId
Date
Marks
.
.
........... This assumes that you have only one teacher per subject. If you want multiple intructors per subject, remove the SubjectTeacher column from the Subjects table and make two new tables
Table <SubjectInstructor>
SubjectId
IntructorId
Table <Instructor>
InstructorId
InstructorName
.
.
May be you can Divide the table based on the class. but still you may have to face several more problems .you better have the tables .
Related
i want to create a platform by laravel 6 included classes students an masters
masters can put the student's scores and the students can see them in their profile...
there is a many to many relation between classes and masters and between student and classes too.
the masters an students are not seperated and all of them store in user table and determine by his role_id
my big issue is uploading of scores by masters... i am extremely confused
has any one any idea ?
What you might want to simplify things is an associative table of users, classes, and scores (I've drawn a diagram for you https://dbdiagram.io/d/5e9787f039d18f5553fdabb1). With this table, you can query pretty much all you could ever want.
Now all you need to do is configure privileges based on user role. A master can read from and write to all class_user_score entities where if there is a record of him being in a class, he can read and CRUD all class_user_score entities with the same classId. A student can only read class_user_score entities with his userId in them.
Unfortunately, I can't help you with the Laravel implementation (they also call an associative table a pivot table for some weird reason) since I'm more of a React, Nodejs type of guy, but I hope this at least helps you to reason about the problem.
I am creating a database for to manage companies and their products(category) and customers. I have designed my database but i want to be sure if my table does not foul the rules of database schema.
users table and product table are linked many to many (having a pivot product_user).
In that instance,
user 1 can have enter a product called hardware
so in the pivot table, product_id : 1 & user_id : 1
user 2 can also enter the same product called hardware
so in the pivot table, product_id : 2 & user_id : 2
Is it a good way to do this? I am new to laravel now. Please help. Thank you
Yes this is a good way, but I would suggest you use "company" instead of "user". This way the naming is clear for everyone.
You might want to read the official documentation of relationships. The examples are also very useful and easy to understand.
Beside the fact that this is not a PHP nor a Laravael nor a MySQL (as a product) question, the real question is what should this many to many relationship stands for?
This is all about general database schema design. We can't tell you if this is right or wrong because we don't know what its meant to be.
If you you can build sentences like "A User has/have zero, ore or more Products" and at the same time "A Product is used by/belong to zero, one or more Users" than this is a good indicator that a Many to Many Relationship is required.
But there could be exceptions where the many to many relation ship is more than just a linking table. Because if a user bought a product than this is most likely a litle bit more complex.
e.g. at an online shop a user can do one ore more purchases, but one purchase belongs only to one user. The purchase do include one or more Products, and the a Product can be part of one ore more purchases. And than there is billing and shipping and all the stuff involved. In this case you could do a direct relation between user and products, but what dose it tell you? What if a user buy a product more than once?
There are situations where you could think that a many to many would be a good idea but in fact it is not (see above) because you create redundant data and/or break data integrity. The Process to avoid this is called normalization: https://en.wikipedia.org/wiki/Database_normalization
A good example of an many to many relation ship is User and Privileges.
There are users and there are privileges that an user can have. So a user can have zero, one or more Privileges and a privilege can be applied to zero, one or more Users.
So if you ask if product_user is a good way to do it the real answer is: it depends!
Hi I'm just getting into PHP and MySQL and English is my second language so excuse me while I try to describe my question well.
I'm trying to create a feedback system where students can leave feedbacks about teachers. A student log in pick a subject first, then find a teacher who teaches that subject and can leave feedback of that teacher. All the feedbacks of a teacher can be seen by public(no require login) And the teacher can log in have look at the feedbacks and mark them as read, once a feedback is marked as read it won't be shown publicly again .
The problem I'm having is not about the idea itself or the login system etc, it's about the database structure. Mainly the teachers feedback database, first the teachers are categorised by subjects, then each individual teacher need to store feedbacks, and those feedbacks can be active(not read yet) or inactive (read).
Since I'm new to PHP and MySQL I don't know how to design the database to be effective, let's give a problem as a example "Display the numbers of active feedbacks of a teacher" I can think of few ways to approach this, but can't decide which way is the best.
SOLUTION 1, One massive database to store everything , First it needs to filter the database by the subjects, then filter by the teacher name/id then filter out the inactive one then count up how many active feedbacks are there
SOLUTION 2, give each an individual database, and when the student leave feedback it gets stored directly into an active database for that particular teacher , when the teacher mark it as inactive it will be moved to a different (inactive) database of that teacher, so to find out the numbers of active feedbacks just simply count the number of data in that active database.
SOLUTION 3, combine solution 1 and 2, because each teacher can only teach one subject, so we create big databases for each subject, and for each subject we create an inactive database where we store inactive feedbacks, when a feedback is marked as read it will be transferred to that database. Then to find out numbers of active feedbacks we can filter the subject to find the teacher and just simply count up the numbers of feedbacks that teacher have because all the inactive ones will be at a different database.
I hope I did not confuse you with my description, I would really appreciate if any of you can tell me the most efficient way to build database for this problem in PHP and MySQL. Thanks!
Edit 1: sorry I do mean Tables rather than databases, so the question is whether I should create multiple tables for this problem or stick with one.
You could first have student table and teacher table. In your feedback table you can have columns: student, teacher, comment, time
Its better to have multiple tables,for teachers and students and it would be good if use log in functionality too.mainly make sure that design a over all flow of steps,its doesn't be be good choosing subjects and teachers separately,think it in such a way that as soon as you select subject an subject,the appropriate teacher of that particular subject should be also be selected.Better create an clear flow of implementation.
I am learning PHP the fun way, by making something useful. I'm making a personal PHP/MYSQL website for tracking watched episodes of tv-shows, and it's going quite good so far, albeit messy.
I have a user table, a episode table and an series table. Each of these are self explanatory I guess. What I want to do is make each user in the user table able to track what episodes have been watched. (Each single episode is in the episode table with a field that joins it with the Series table to keep track)
What I cannot get my head around is this:
How can I track if said user has watched said episode?
The only solutions I've come up with is
Add a field in the episodes database with the userID and mark them as 0 or 1, which isn't a very nice solution.
Even worse; each user has a "watched_id" field with several values for each watched episodes.
I know enough to know that this is not a good approach,
how can I approach this more effectively?
You need to create a many-to-many relationship using a mapping table ie. named "watched" with the following fields
id
user_id
episode_id
watched_at
...
Hope that helps. There is a lot of documenteation on the net if your searching for "many-to-many relationship", here is just an example:
http://www.joinfu.com/2005/12/managing-many-to-many-relationships-in-mysql-part-1/
I've done quit a bit of programming with php/mysql on small scale personal projects. However I'm working on my first commercial app that is going to allow customers or businesses to log in and perform CRUD operations. I feel like a total noob asking this question but I have never had to do this before and cannot find any relevant information on the net.
Basically, I've created this app and have a role based system set up on my data base. The problem that I'm running into is how to separate and fetch data for the relevant businesses or groups.
I can't, for example, set my queries up like this: get all records from example table where user id = user id, because that will only return data for that user and not all of the other users that are related to that business. I need a way to get all records that where created by users of a particular business.
I'm thinking that maybe the business should have an id and I should form my queries like this: get all records from example where business id = business id. But I'm not even sure if that's a good approach.
Is there a best practice or a convention for this sort data storing/fetching and grouping?
Note:Security is a huge issue here because I'm storing legal data.
Also, I'm using the latest version of laravel 4 if that's any relevance.
I would like to hear peoples thoughts on this that have encountered this sort problem before and how they designed there database and queries to only get and store data related to that particular business.
Edit: I like to read and learn but cannot find any useful information on this topic - maybe I'm not using the correct search terms. So If you know of any good links pertaining to this topic, please post them too.
If I understand correctly, a business is defined within your system as a "group of users", and your whole system references data belonging to users as opposed to data belonging to a business. You are looking to reference data that belongs to all users who belong to a particular business. In this case, the best and most extensible way to do this would be to create two more tables to contain businesses and business-user relations.
For example, consider you have the following tables:
business => Defines a business entity
id (primary)
name
Entry: id=4, name=CompanyCorp
user => Defines each user in the system
id (primary)
name
Entry: id=1, name=Geoff
Entry: id=2, name=Jane
business_user => Links a user to a particular business
user_id (primary)
business_id (primary)
Entry: user_id=1, business_id=4
Entry: user_id=2, business_id=4
Basically, the business_user table defines relationships. For example, Geoff is related to CompanyCorp, so a row exists in the table that matches their id's together. This is called a relational database model, and is an important concept to understand in the world of database development. You can even allow a user to belong to multiple different companies.
To find all the names of users and their company's name, where their company's id = 4...
SELECT `user`.`name` as `username`, `business`.`name` as `businessname` FROM `business_user` LEFT JOIN `user` ON (`user`.`id` = `business_user`.`user_id`) LEFT JOIN `business` ON (`business`.`id` = `business_user`.`business_id`) WHERE `business_user`.`business_id` = 4;
Results would be:
username businessname
-> Geoff CompanyCorp
-> Jane CompanyCorp
I hope this helps!
===============================================================
Addendum regarding "cases" per your response in the comments.
You could create a new table for cases and then reference both business and user ids on separate columns in there, as the case would belong to both a user and a business, if that's all the functionality that you need.
Suppose though, exploring the idea of relational databases further, that you wanted multiple users to be assigned to a case, but you wanted one user to be elected as the "group leader", you could approach the problem as follows:
Create a table "case" to store the cases
Create a table "user_case" to store case-user relationships, just like in the business_user table.
Define the user_case table as follows:
user_case => Defines a user -> case relationship
user_id (primary)
case_id (primary)
role
Entry: user_id=1, case_id=1, role="leader"
Entry: user_id=2, case_id=1, role="subordinate"
You could even go further and define a table with definitions on what roles users can assume. Then, you might even change the user_case table to use a role_id instead which joins data from yet another role table.
It may sound like an ever-deepening schema of very small tables, but note that we've added an extra column to the user_case relational table. The bigger your application grows, the more your tables will grow laterally with more columns. Trust me, you do eventually stop adding new tables just for the sake of defining relations.
To give a brief example of how flexible this can be, with a role table, you could figure out all the roles that a given user (where user_id = 6) has by using a relatively short query like:
SELECT `role`.`name` FROM `role` RIGHT JOIN `user_case` ON (`user_case`.`role_id` = `role`.`id`) WHERE `user_case`.`user_id` = 6;
If you need more examples, please feel free to keep commenting.