I'm trying to figure out what is the best practice with selecting data from two related model.
I have a model (and a db table) "person" and then i have a model (and a db table) comment. There may be multiple comments for one person and comment has "person_id" column.
I have two cases in particular.
First i need to show persons profile with all his comments.
In my controller do I select the needed person through my person model and then select all the comments through my comments model? Or is it more correct for person model already return person with all comments?
I myself would guess that first option is ok.
Second case is where i need to show all latest comments with name of the person who made the comment.
So in my controller is it correct to select all latest comments from comments model and then select a person for each or them? Or is it more correct for the comments model to return comment with person name included?
In this case i would guess that second option is better. It seems really strange to first select comments and then iterate them and select a person for each of them.
So im kind of confused because case 1 and 2 seem similar but i would use different solutions for them. Which one is correct?
Related
I have users, meetings and comments tables and I want users to be able to post comments on users profile and meetings.
I know how to make one to many relationships for users and comments tables, but I want all comments to be saved in one table and show comments on users profile and meetings.
This is my table structure:
users
id
name
comment_id
meetings
id
name
comments
id
user_id
comment
TL;DR The solution is to use polymorphic relationships which Laravel makes really easy.
IMHO I don't think that a many-to-many relationship will do the job. It would mean that:
a user can post multiple comments. Okay
a comment can belong to multiple user. Weird
a meeting can have multiple comments. Okay
a comment can belong to multiple meetings. Weird
Plus you would likely need two comments tables to achieve that. For instance a comment_user table and a comment_meeting.
The kind of relationship that would fit the most your situation is the polymorphic one. The name can be scary because it comes from ancient greek. But the concept behind the name is very simple. And Laravel makes polymorphic relationships very easy. You will certainly recognize your situation in the example given in the Laravel documentation ;)
While saving comment, also keep a field named model (or anyone you like) to identify users profile and meetings
HTH
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.
I am working on a little project where a user submits an article to MySQL, and then PHP send the post to the screen. So far so good.
Now i want to extend it to a "two level" post system, where people can comment on the articles.
The case is, i dont know how to do that.
The table i use for storing articles:
TABLE: posts
id user date avatar signature post
Should i make a new row named comments in the posts table, or should i place the comments in a seperate table? one for articles, one for comments?
All help is much appreciated.
Depends on how you use it on your website. You have to ask: "are my articles and comments essentially the same concept?" If yes, then use one table, if no, use two. On most websites articles work differently, can be categorized, editted etc., and usually need a different fields which would clutter the comments table... so in that case two tables are more reasonable. But if you conclude that on your website articles and comments are generally the same (but try to think future proof: wouldn't you need to add some article functionality in 2 months?) then you can think of articles also as of comments and have one table for them.
If you decide to merge things to one table, and you realize that you need another column to distinguish type of the post, and that some columns remain unused for some types, it is a clear warning signal you should have two tables!
This is a little subjective, but I would just set up a parent/child relationship on your posts table, make a parent_id column that is a foreign key for the id column in the same table. for extra credit, you can make it a nested set relationship which will allow you to pull the parent and all the children in one query
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.
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.