I have tables as seen here
An Athlete has many test days (e.g. one for each year), an Institution has teams e.g. Redham High School Rugby U14 Level. The team table is composed of the Institution, a sport and a level. Sport and Level are maintained in Codelist, which is just a table to maintain entities that are not big enough to be a table. Almost like replacing the hard coding of droplists.
Question 1: I don't see that the Codelist is related to the Team table, since Code list store unrelated info as well, like Country names, province names etc. Example of Codelist data below. Should they be related?
Question 2:
When creating a Test day record, I need the user to select for which team this athlete is getting tested for. I'm getting the Team records, but how do I now access the sport and level names from the Codelist?
I can't do $team->sport->name as they're not related tables.
Below is my current code. How do I get user friendly values for sportcode and levelcode e.g. Rugby U14.
$teams = Team::whereHas('Institution', function($query){
$query->whereClient_id(1);
})->get();
I can with $teams loop get the sportcode and level code and now write separate queries to fetch the names from the codelist. This would send 3 collections back to the view and doesn't seem the eloquent way. Advice appreciated.
Related
Hello I am working with Laravel,
I have to create two simple models, let's say Stores and Books.
Stores can have one or multiple Books and Books can belong to many Stores.
Of course I will use a many to many relationship, with a pivot table.
Books the can have different prices depending the store.
I think a separate table can only complicate things, in my mind the pivot table associating books and stores should have a price column, but pivot tables only contains store_id and book_id.
Should I create a book_prices and associate it with books and to stores? What is the best approach?
You are free and able to set other attributes on your pivot table. You can read more about it in the docs.
https://laravel.com/docs/9.x/eloquent-relationships#retrieving-intermediate-table-columns
You have to define the relationship accordingly, the following should clarify how this works. In this example you use the many-to-many relationship and add the price column to every retrieved pivot model.
public function books()
{
return $this->belongsToMany(Book::class)
->withPivot('price')
}
For example, you are able to access the pivot column in a loop like this
foreach ($shop->books as $book)
{
echo $book->pivot->price;
}
You can define additional columns for your pivot table in the migration for the pivot table, and then when defining the relationship use withPivot to define the additional columns so they come through in the model:
return $this->belongsToMany(Book::class)->withPivot('price');
(Adapted from the Laravel documentation, see https://laravel.com/docs/9.x/eloquent-relationships#retrieving-intermediate-table-columns)
Depends on the complexity of your case, but yes, you have two options for it. Let's say that the pivot table is called as book_store:
Directly adds price column to book_store. This is obviously the simpler option. The drawbacks are:
The history of the price changes isn't logged. You'll have to create another table for logging if you want to keep this history information.
Changes made to price will directly change the price of the related book_store record. Meaning that a price is being updated "live" e.g users cannot update the price now but "publish" it some time later just like this example in the doc.
Create a new, different table to store the price. This may seems relatively more complex, but it may also be more future-proof.
Basically, you get 2 things that you miss in the first option above.
Don't think too much about book_store being a pivot table. One way to see it is like this: book_store IS a pivot table from books and stores tables viewpoints, but it's also just a normal SQL table which could relate to any other tables using any kind of relationships.
If you want to implement this, make sure to create a primary-key in the book_store table.
Alast, it all depends on what you need. Feel free to ask if you need more insight about this. I hope this helps.
I am new to Laravel and need some help with what might be a basic question.
Race horses (can) have many owners. Owners (can) have many race horses. However, owners can buy and sell shares in race horses. At any point in time it must be possible to determine the share holding of each race horse.
My pivot table is defined as follows:
Schema::create('horse_owner', function (Blueprint $table) {
$table->id();
$table->foreignId ('horse_id');
$table->foreignId ('owner_id');
$table->date ('effective'); // the date when the transaction occurred
$table->integer ('shares')->default (1); // the number of shares + or -
$table->timestamps();
});
My Horse model includes a withPivot for effective and shares and I can show these in the Horses view. However, where an owner buys and sells shares, I would like the resultant number of shares to be shown.
The SQL query to find the current owners of a horse on a certain date looks like this:
SELECT `owners`.*, SUM(`horse_owner`.`shares`) AS `share_total`
FROM `owners`
INNER JOIN `horse_owner` ON `owners`.`id` = `horse_owner`.`owner_id`
WHERE `horse_owner`.`horse_id` = ? -- some horse
AND `horse_owner`.`effective` <= ? -- some date
GROUP BY horse_owner.owner_id;
While seeing the individual "transactions" is a necessary function, this share total will be mostly more useful than the individual transactions (e.g. summary reports, billing) and so being able to extract it easily for one or more horses or owners will be useful.
How does one set this up in Laravel and are there any best practice suggestions?
EDIT:
Based on other solutions, I've attempted the following:
return $this->belongsToMany (Owner::class)
->selectRaw ("`owners`.*, SUM(`horse_owner`.`shares`) AS `share_total`")
->withTimestamps()
->groupBy ("horse_owner.owner_id");
However, this results in an error because the query still includes "contains nonaggregated column horse_owner.id which is not functionally dependent on columns in GROUP BY clause".
I have a table customers with the fields id, name and so on.
One table doctors with the fields id, name.
Then there is one table subject_areas which has all subject areas which a doctor can have. The fields are id, text.
So, each doctor can have multiple subject areas. There is one pivot table doctor_subject which is a belongsToMany relation.
Here is my problem: A customer can have multiple doctors, but only for a specific subject area. I tried it with a new table customer_doctor with the fields id, customer_id and doctor_subject_id. But how do i map this in Eloquent?
Issue was in relation between tables. After chat clarification this came out as solution:
Html form is written in a way that customer first choose doctor, then depending on selection choose several of his available areas.
In that scenario customer needn't to be related to areas directly and should be related to areas only over relation with doctor.
Also as side note, if needed deeper relations, models on pivot tables could be created and used as well.
SQL Server 2012 MVC3 EF4.3.1 Code First project.
I have a Teacher and Student table with a one to many relationship. The Teacher’s tables Id will be used as the account number so its Id numbering needs to be separate from the Student’s. I would like to create a Person table (containing shared properties such as First, Last, Phone, Email) to reduce redundancy on the properties. Person will also have a one to many relationship to an Address table.
I’ve thought of trying a Table per Hierarchy model with Teacher and Student inheriting from Person but then the Id sets would not be separate and I would have to have a one to many relationship internally on the Person table. I could generate the ID’s through code but is an internal one to many doable or practical?
Another scenario would be to setup Person as a child table with a one to one between and Teacher and Person and a one to one between Student and Person but I’m not sure how or if it’s possible to have two separate one to one’s on a table.
Is there a practical way to do what I want or should I not worry about the redundancy and not use a Person table? If I went that route would it be possible to have two separate one to many relationships to an Address table (Teacher-Address and Student-Address)? Or for that matter a one to many (Teacher-Address, teacher may have an additional shipping address) and one to one (Student-Address)?
Thank you
Another way to do it is to have a one to one between a Person and a Role table. Teacher and Student are merely roles in this arrangement. A given Role can be fulfilled by many Person instances.
You could also do a Person table with an IsTeacher flag.
I can see two possibilities:
One: Go with your Student and Teacher inheriting from a base table of Person and not worry about the 'redundancy'. It's not a redundancy because your relating a Student and a Teacher not a Person to a Person and so in your database and DOM the Person table and Person class know nothing of the Teacher to Student relationship, it only knows that its a person. The teacher and student relationships are stored in there respective types, not the person type. Also, look at Table per Type instead of Table per Heiarchy. It's much cleaner and crisper looking in the database and you don't get all the information of each type in the heiarchy in one table.
Two: Create a table that specifically holds information that both Students and Teachers share and have that related to both the Student and Teacher table separately. You could call it something like "ContactInformation".
Being a teacher and being a student are roles of people, not types of people.
You should have a table for People, a table TeachCourse to say that a Person is the teacher of a course (which in some cases are multiple teachers), a table AssistCourse to say which persons are attending a class as a student. You might have people that teach a course and assist another course, and that wasn't properly modeled in your first version.
You can also create a ContactInformation or ShippingInformation table for People to specify all their data (Some people may have multiple phones, or emails to).
I'm having a hard time designing a relationship with a few models in my project.
The models are: band, musician, instrument
Bands have multiple musicians
Musicians have multiple bands and multiple instruments
That’s all pretty straightforward, but I also need to keep track of what instruments a musician has for a particular band. So in a sense, I guess, bands have multiple instruments via the musicians.
In the tables, I was going to add instrument_id to the bands_musicians linking table, but I need a musician to be able to have multiple instruments for a band, so I was thinking it would need to go in the musicians_instruments table.
What's the best way to set up the relationships with these models?
Thanks for your time!
Musicians would have a one-to-many relationship with both bands and instruments. So create your musicians table and add all of the information relavent to the musicians themselves into that table.
Create an instruments table to hold information about instruments, and do the same for the bands. That will take care of all of your individual items.
Then create something like 'band_assignments' table that just has the id of a band and the id of a musician and links the two together. Create an 'instrument_assignment' table to do the same thing.
Now when you query a musician you can left join all of these tables together to get the data that you need or selectively join on just instruments, just bands, or sort by 'join date' and limit to get the last band they joined or the last instrument they learned.
Basically 5 tables should cover it all.
musicians (musician_id, first_name, last_name)
bands (band_id, name)
instruments (instrument_id, name)
band_instument_assignments (musician_id, band_id, instrument_id, date_played)
As you can see in the edited version above you will have multiple rows in the 'band_instrument_assignments' table--one for each instrument that each user played in each band. You will need to use some GROUP BY and LIMIT clauses to get the data you want, but it should work for you.
See:
How to handle a Many-to-Many relationship with PHP and MySQL
That should give you an idea on how to go about designing your database structure.
someoneinomaha
Maybe you need 4th model, which will cover and union all of her children entities, e.g. called like 'Mus Model'(or whatever you want) and have some methods like:
get_bands()
get_instruments()
get_musicians()
get_instruments_by_musician()
get_musicians_by_band()
get_instruments_by_band()
get band_by_musician()
and so on...It'll provide you needed data and will not brake entities relationships, imho.
I might be a little late to the party here and I am no database expert but I have found that drawing out your DB schema helps immensely. Just make boxes and fill in your table names and columns then draw arrows to define your relationships and it should be a lot clearer as to how you should structure things and whether you need to add a table to join two other tables.
If all else fails, just copy a schema from databaseanswers.org. I'm sure there is one there that would probably help you.