Joining two tables Laravel - php

I would like to have some feedback on how to join two tables using Laravel. I have read the documentation but still I am a little bit confused. And I'm still thinking on how to handle the problem. See... I have two tables one for the kids information and the other for the vaccines, I decided to put it apart because there are a lot of vaccines and I don't want the user to input every vaccine each time they add a new kid to the system. I am planning on making some type of checkboxes for the administrator to select the vaccines each kid has, but then I have the date, so I don't know what will be the best approach.
And one of my questions is, how will I retrieve the data from the vaccines table when the user is filling out the kids information? Or do you guys have a better sugestion? I already have the table of the kids up and running, but now I have to add the vaccines.
I would glady appreaciate your help. I will also leave a picture of the two tables.

To my understanding you will need to keep another table that would manage the interaction between kids and vaccines lets say kids_vaccines.
This means that, every kid that receive one or many vaccines would have their record added with timestamp of the time the vaccine(s) was received
An example would be:
Having KidsVaccine model with relationship with Kid and Vaccine like
public function kid()
{
return $this->belongsTo(Kid::class, 'idkid');
}
public function vaccine()
{
return $this->belongsTo(Vaccine::class, 'idvaccine');
}
And both your Kid model and Vaccine model can bear a hasMany() relationship with KidsVaccine
This means that, in lets say kids_vaccines table you would be managing idkid and idvacccine as both foreign keys (ofcourse your timestamps are here, so as to know when a vaccine was applied to a kid).
This results that you can easily create a kids with vaccines retrievable from the vaccines table.
If there is anything unclear you can point it.
Hope this helps :)

Related

how can i make a relation between master calss and student in my platform

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.

Php: use data from a join table with mvc

Heya I am novice web dev or actually I am still in education.
I got this situation Where I have 3 tables lets say : Students, Groups and a join table Student_group.
I put my data from Students in the student model and from groups I put its data in the Group Model so I can use it my application. But I store a date in the Student_group table because I need to know when a student changed from a group.
So my question is in which model do I put this date? Do i need to make a new model for the combined tables or do I need to add another attribute to the student model?
Thanks in advance ;D
That depends. Will the student be in many groups, or one?
If one (one to one relationship), you can decide where to put it. The column could be in either the Student table, or the Student_group. In this case, though, it may be advisable to flatten the data and simply add group columns in your Student table. You decide that as well - if it seems unnecessary to have a join for a one to one relationship (usually it is, not always), then flatten it. In either case, the data should stay in its respective model. That said, you should use the Student model if you handle it in the Student table.
If many (one to many relationship), I'd advise putting it in the Student_group table and leaving it in that model as well.
All in all, the model should be a direct reflection of the data it's representing. You could make some methods inside your Student model to make it easier to get the date, for example. However, I'd personally handle that date inside of the proper model, Student_group. As mentioned, the model should be a direct representation of the data. Again, though, there's nothing wrong with making things a bit easier by creating some methods that help out the developer.

PHP MYSQL Show tracker, how to mark episodes as watched

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/

Should dependent rows be fetched in the Model or the Controller?

Let me start with a simple example to show how my data is structured. There are four tables, Employee, Store, Department, and Employee_Department_Permissions.
Departments belong to Stores (for example, the Department table might contain a record for the dairy department of store 5). Employees are given the right to work in Departments through the Employee_Department_Permissions table, which contains the Employee id and Department id.
Let's say an employee can log in to my application and view a list of every store in the database. Next to each store, I want to print out how many departments they can work in at each store. I have an Employee model with a mapper that provides the fetchAll method to accomplish the first part.
But, where should I find out how many departments an employee can work in? In my model wrapper, I can call findDependentRows to do this. Or, I could do it in my controller with raw Zend_Db_Select calls. A third option I was considering would to be just add a column to the Employee table that holds this information, but then I'd need to update a second table when Employee_Department_Permission is modified.
Thank you in advance for any advice.
As a very general rule of thumb, I would suggest you try keep the controller as free as possible from fetching information for the views. This is a task best handled in the model.
Sure it's easy to just fetch from controller, I mean, since we are there processing a request, it would be so simple to just do a quick fetch and push that off to the view. This is where dicipline comes into play. As your application grows you will appreciate having the clean separation this methodology offers you if applied.
My 2 cents, happy coding to you friend.

CakePHP: HABTM + 1

I have a site that scrapes all the episodes from tv.com from certain series.
So my database has a User table, a Show table, an Episode table, a Show_User table (to associate shows with users, HABTM), an Episode_Show table (to associate episodes with shows, HABTM), a Episode_User table (to associate episodes with shows, only as a way of marking them as 'watched').
Now I want to add a way of marking an episode as 'downloaded' too.
So at the moment, the Episode_User table has two fields, Episode_Id and User_Id. Should I create a new table entirely for this? Or just add a field to the Episode_User table?
I'm using CakePHP's automagic features, and don't particularly want to break it. But if I have to, I have to...
Thanks for any advice.
I don't see why you would want to create a new table for episodes a user has downloaded. To me it would make the most sense to modify the Episode_User table to have a field for watched and a field for downloaded, since it's all relating back to the same pair of entities, users and episodes.
However, any time I've stored information about a relationship between two tables in that manner, I've found that regardless of the framework I'm using, the ORM inevitably become more complicated, but I don't think there's any way around there.
With CakePHP for handling those kinds of complicated situations, read up about the model behavior, Containable. It's not very well documented in the CakePHP book, but is really quite useful in a situation where you need to use the fields in Episode_User, for example, if you needed to find all of the users that had watched a particular episode, but not downloaded it.
Also, it occurred to me, while reading your post, that you could possibly make your data model more simple by having a hasMany relationship between shows and episodes. An episode will never belong to more than one show, so your episodes table could just have another field, show_id, which related back to the show table, and you wouldn't even need the Episode_Show table.

Categories