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.
Related
I have a many-to-many relationship between an incident model and a Patient model. An incident can have many patients and a patient can be involved in many incidents.
Should it occur that a user creates duplicates of a patient model we want to be able to merge those two patient models into one. This means that I want to move the incidents that patient 1 is involved in to patient 2 including additional attributes that are sitting on the pivot table.
I've tried something as simple as
Casualty::where('patient_id', $patientOne->getKey())->update(['patient_id' => $patientTwo->getKey()]);
But this doesn't work. Using the updateOnExistingPivot() method would mean I need to iterate over every incident for patient 1 and run a separate DB query to update the patient to patient 2.
I've also tried updating the record like this
$patientOne->incidents()->update(['patient_id' => $patientTwo->getKey()]);
This also doesn't work because there is no patient_id column on the incidents table.
How can I achieve this or am I doing something wrong?
Not sure if I understood you, you want to group more patients into the same accident? You could go with the belongsToMany relation and make one pivot table. Then, when you want to update the data simply use the sync method.
You can also try storing them with json_encode() in one column which will hold only users ID's and later on retrieve them.
Sorry, can't give more info since the question is not described that well.
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 have a general question about how to implement the best practice of model structure for an application I'm building in Laravel 5.
So, at the moment I have things set up like this:
'user' model and table: id, email, password, admin level - this is really just the info for authenticating login.
'user-details' model and table: id, userID (foreign key for user table id field), name, address etc - all the other details
'lesson-type' model and table: id, teacherID (foreign key for user-details table id field), lesson-label etc - info about different types of lessons
At the moment I have a Teacher Controller in which I'm passing through to the view:
- The info from the User table
- The info from the User-details table
- A list of different lesson types for the teacher from the Lesson-type table
But I kind of feel that all this should be tied together with one separate Teacher model which would extend the User-details model (and probably which in turn should extend the User model), but wouldn't have it's own table associated with it, but all the info pertaining to either updates for the User-details or the Lesson-types table would be stored in those relevant tables. Would this be correct?
(I should also say that users may alternatively be parents rather than teachers, and so would I would have a separate Parents model for all the properties and so on associated with parents)
I would then pass only the Teacher model object into the view and thus gain access to all the teacher info such as personal details and array of lesson types.
As I'm typing, this is sounding more and more to me like the right way to go, but it would be great to get some advice.
1 - technical implementation: I guess in the Teacher model, I'd populate all the relevant teacher into class variables (Name, array of lessons etc) in the constructor?
2 - am I over complicating this structure by having both Users AND Users details tables?
3 - Does what I'm proposing make the most structural sense in Laravel?
4 - just another thought I've just had, should the teacherID in the lesson-type table actually refer to the User table rather than the User-detail table... so user-detail and lesson-type would both be direct children of the user table??
Very much obliged for any help :)
You shouldn't extend models like that unless there is a clear inheritance. From a logical standpoint, it just doesn't make any sense since you'll have to overwrite most of what is on the User model anyway. And what you don't overwrite will be incorrectly mapped to the database because they are 2 completely different tables. What you actually want to do is utilize Eloquent relationships.
For clarity, I am assuming this basic structure:
users - id
teachers - id, user_id
user_details - id, user_id
lesson_types - id, teacher_id
Those should be 4 completely different models all interconnected using the Model::belongsTo() method. So the Teacher model would be
class Teacher extends Model {
public $table = 'teachers';
public function user() {
return $this->belongsTo('App\User');
}
}
When you query for a teacher, you can do Teacher::with('user')->get(). That will return all records from the teachers table and on each instance of the Teacher model, you'll be able to call $teacher->user and get the User instance associated with that teacher. That is a full model, not just extra data, so you have access to everything on the User Model, which is generally the main reason for extending
For your list of questions:
I may be misunderstanding you, but this isn't how an ORM works. I'd suggest going back and reading through the Eloquent docs (if you're running 5.0, I suggest reading 5.1's docs since they are much, much better)
It will depend on who you ask, but I tend to think so. If the data is clearly related and there is no reason for it to be shared across record types (for example, I generally have an addresses table that all records reference instead of having 5 address fields repeated on multiple tables), I believe it should all be on one table. It just makes it more difficult to manage later on if you have it in separate tables.
There will be those who disagree and think that smaller scopes for each table are better and it will likely allow for quicker queries on extremely large datasets, but I don't think it's worth the extra trouble in the end
No, as I have explained above
The teacher_id column should reference the teachers table, assuming that lessons belong to teachers and cannot belong to just any user in the system. Using the ORM, you'll be able to do $lesson->teacher->user->userDetails to get that data
I really think you need to go back and read through the Eloquent docs. Your understanding of how Eloquent works and how it is meant to be used seems very basic and you are missing much of the finer details.
Basics
Relationships
Laracasts - Laravel Fundamentals - You would benefit from watching Lesses 7-9, 11, 14, and 21
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.
I would like to have categories, and rankings for my content and users respectively, and I am not sure how to go about implementing this using CakePHP conventions?
Do I need to create a model?
That depends entirely on what these categories are supposed to do and not do. You could simply define a number of constants that you use for categorizing stuff. But, are categories...
subject to change? Do you want to add more eventually?
editable? May you want to change their names?
nested?
supposed to have more attributes than just their id? Names, descriptions?
If you answered Yes to any of the above, you'll want to store them as data in the database. This is independent of Cake, it's just sane data modeling. For Cake that means you'll need to create a model. The same goes for ratings.
So you'll have these tables:
users
hasMany ratings
categories
hasMany contents
contents
belongsTo categories
hasMany ratings
ratings
belongsTo users (polymorphic)
belongsTo contents (polymorphic)
You may want to separate user ratings and content ratings into two tables instead of using a combined polymorphic table (which just means that you have an extra column keeping track of whether a rating is for a user or for content).
i guess you are looking for something like this IF you dont want to use a model:
http://www.dereuromark.de/2010/06/24/static-enums-or-semihardcoded-attributes/
one possible approach to use "enums" for things that maybe only have 1-5 states.
if you have more than 10 or you want to be able to dynamically modify them (label, active/inactive) you will need a separate table and model relation.