I have
users
id
username
companies
id
areas
id
area_company
id
area_id
company_id
area_company_user
id
area_company_id
user_id
company_user
id
company_id
user_id
area_user
id
area_id
user_id
where
one user has 0 to many areas AND one area can have 0 to many users
one area can have 0 to many companies AND one company can have 0 to many areas
one company can have 0 to many users AND one user can have 0 to many companies
one area_company can have 1 to many users AND one user can have 0 to many area_company
area_company_user has attributes specific to that kind of user
Also, I'm structuring the routes in the following manner
/users - all existing users
/areas - all existing areas
/companies - all existing companies
/areas/{area}/companies - all existing companies in a specific area
/users/{user}/companies - all existing companies from a specific user
/companies/{company}/areas - all existing areas the company is in
/areas/{area}/companies/{company}/users - all existing users from a company that exists in a specific area
For 1., 2. and 3. I'm creating controllers that follow the next pattern
AreaController with methods index(), create(), store(), show(), edit(), update() and destroy()
GET /areas, index() method,
GET /areas/create, create() method,
POST /areas, store() method,
GET /areas/{area}, show() method,
GET /areas/{area}/edit, edit() method,
PUT/PATCH /areas/{area}, update() method,
DELETE /areas/{area}, destroy() method.
There's now basically two cases left from that route list
Case 1: 4., 5. and 6.
Case 2: 7.
My question is, should I create new controllers for each case since I'd like to perform various actions in each? If yes, that'd mean, respectively
Case 1: AreaCompanyController, UserCompanyController and CompanyAreaController
Case 2: AreaCompanyUserController
Note: this was a helpful answer but didn't exactly address my concern.
You can see there is already something called nested resource in docs which can cover your cases 4,5,6. In docs there is PhotoCommentController which you've described that you're using it (question case 1).
For question case 2 you can for example make model for pivot table and have it that way for route and controller. For example AreaCompanyUserController if I understand well, you have here area_company pivot table with association of user. So many users can be part of same area_company association.
You can circumvent Area and Company models use with use of AreaCompany model that would be the pivot model. Knowing id of that pivot model you can easily get associating area, company and users.
class AreaCompany extends Pivot
{
/** code here */
}
Having this, you can name your resource route /area-companies and /area-companies/{$areaCompany}/users to avoid triple nesting.
I presume any of these decisions have own consequences like subdirectory planning for controllers, form request files, providers, sometimes even route files.
Probably heard and read for thousand times, but important is to stick with consistent way of it. Consider what could be lesser technical debt in some potential upgrade.
In order to simplify the debugging and maintenance process of the project it's better to define the controller for each case in case if anything goes wrong it's easy to debug and solve the problem so you will be having
AreaController , UserController , CompanyController
Related
Obviously this does not exist but I am looking for a way to implement it.
Example, I am playing a game where I have 3 teams but I can only be actively playing for one team at any time and when I switch team I essentially starting from the beginning but I would like to retain the progress if I switch team.
My tables would look something like this:
Users:
active_team_id
TeamProgress:
user_id
team_id
team_level
team_xp
TeamNames:
id
team_name
So there would only be 3 teams defined in TeamNames and while any one of these 3 are active (as set in active_team_id in the users table) then I want to be able to directly target it with something like
$user->teamProgress->update()
and update the active team directly.
Similarly I would like to do something like
$user->teamProgress->get()
and just get the team progress for that users active team while a few others may exist within team progress.
Then if I switch the active_team_id on the user table and do the same calls above I now update / get info for the second team specified in active_team_id
Is there a way to do this with a relation or am I overthinking this and better off doing this by just directly targeting the TeamProgress model using the information I already have as a user?
$teamProgress->where('user_id', $user->id)->where('team_id', $user->active_team_id)->get()
You can try this package https://github.com/topclaudy/compoships. It allows you to define relations by matching multiple columns. For example
class User extends Model
{
use \Awobaz\Compoships\Compoships;
public function activeTeamProgress()
{
return $this->hasOne(TeamProgress::class, ['id', 'active_team_id'], ['user_id', 'team_id']);
}
}
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
I am trying to get my head around some relationships between models in Laravel.
I would like to define the relationship between the following models:
User - the users
Campaign - a campaign
Call - a phone call
Lead - Lead/client
Sale - A sale
Appointment - A scheduled phone call.
This is the way the relationship should be:
A user can be assigned to many campaigns.
A user can have many calls.
One user can have many appointments.
One call belongs to one user.
One call belongs to one campaign.
A campaign can have many calls.
A campaign can have many sales
A lead can be assigned to many campaigns.
A lead can have many sales
One lead belongs to one user in one campaign.
One lead can have many calls
One sale belongs to one campaign
One sale belongs to one user
One appointments belongs to one lead.
I uncertain about how to setup the relationship. Its easy with the one-to-one or many-to-one.
But what about this:
Call->User (one-to-one)
Call->Campaign (one-to-one)
Campaign->Call (one-to-many)
User->Call (one-to-many)
Hopefully I managed to explain it clear enough. Thanks.
I'd recommend reading the Laravel docs on relationships again.
Taking the Call/User relationship as an example, here's what you're looking at:
User --------> Call
(one) (many)
This is clearly a one to many relationship. And if you want to set up both sides of this relationship in terms of an Eloquent model, the relationships are this:
A User hasMany Calls
A Call belongsTo a User
These terms are taken directly from the documentation, in the section entitled One To Many.
So, in code...
User Model
public function Calls()
{
$this->hasMany("Call");
}
(notice that I've made the method name plural - this is my own preference, since using $user->Calls will return a collection if items).
Call Model
public function User()
{
$this->belongsTo("User");
}
Rather than taking the two sides of a relationship in isolation, as you seem to have done in your analysis, consider both sides of the relationship at the same time.
I'm trying to figure out the appropriate relationship setup/schema for the following scenario and I suppose I'm a bit unclear as to the relationships themselves.
My models: Accident and People.
An accident may involve many people. A person may be related to many accidents.
For example: An accident happens to Abe and Bob. Abe may be the related to multiple accidents.
I have an accidents table, a people table and an accidents_people table with the appropriate schema. I want the user to be able to add an accident independently of a person, and a person independently of an accident, and then when they edit an accident, link it to multiple people. Is this possible?
$people = $this->Accident->Person->find('list'); //should give me list of all people
$this->set('people', $people); //should allow me to access a list of all people in view
TLDR:
What you're describing is the "Has and Belongs To Many" relationship (also known as HABTM):
http://book.cakephp.org/2.0/en/models/associations-linking-models-together.html#hasandbelongstomany-habtm
Note / Another option:
Another option is the HasMany Through, which is basically HABTM, but with a model specifically for the join table. This allows a bit more flexibility if you need more than just the 3 fields in your join table (id, person_id, and accident_id)
Model convention:
If you're following the CakePHP Model and Database Conventions, your "People" model should really be "Person".
It's "okay" to use non-standard, but if you're learning Cake, you're better off trying to stick to them for now.
(looking at your code, which correctly uses "Person" as the model, I assume you just typed it wrong in your description)
I'm creating a project management system which projects are assigned to users
What's the difference between creating a Model ProjectsUser and defining 2 $belongsTo relationship and defining HABTM relationships in both Project and User models? What would be the most correct way, though? And how do I save the data in the projects_users table?
From my experience, if you want to be able to save or delete rows only from the join table (the one with 2 IDs), then it is much more simple using three models associated through both a hasMany and a belongsTo association.
You can also retrieve data from the join table directly and do the queries you want much more easily
This is what CakePHP documentation says refering to HABTM and saving data:
However, in most cases it’s easier to make a model for the join table and setup hasMany, belongsTo associations as shown in example above instead of using HABTM association.
Here you can find more the full text:
http://book.cakephp.org/2.0/en/models/saving-your-data.html#what-to-do-when-habtm-becomes-complicated
I have used this method for a "reads" table (with post_id and user_id) as well as for subscriptions and similar kind of relationships.
The first way is called "hasAndBelongsToMany" [details here].
The second is called "hasMany through" [details here].
The second link relating to "hasMany through" has details and a lengthy explanation about when and why you would want to use it.
Not sure about the specifics of cakephp, but in general defining the relation model explicitly gives you more control over it, for instance if you wanted to do some validation or add callbacks on creation of this relationship.