I have a User model and an Events model. A User has_many Events (can create several events), and Events belong to User. However, since my Events also have a registration, I thought the best way would be to add a pivot table users_events_table that would contain all the registration, and now both Models pass to the belongs_to relationship.
Is there any way to maintain both relationships?
Yes - you're probably after a has many through relationship. It works similar to a belongs to many relationship except the pivot table is a first-class model, which means you can attach additional functionality to it. A user can have many events through registrations and vice-versa.
If you don't actually need that much additional information on the pivot table - maybe you just need created_at/updated_at timestamps then you can get away with belongs to many and pop withTimestamps() on the end - Laravel will handle that for you. It does allow you to add more columns on that pivot table but they can get tricky to manage depending on you use case, which is where has many through might become a better solution.
Related
I have the following Entity Relation diagram (MySQL), which I made for a small project(for the university). I would like to know if the relation between PK and FK is properly made.
I am aware that token should not be used in the users table.
Don't know why my brain cannot comprehend the relationships properly. As far as I've managed to come up is:
Many users can have one role. (User, Admin, University)
One role can be belong to many users.
One user can have one event.
One event can belong to one user.
One user can have many attendings.
Many attendings can belong to one user.
Many events can have many attendings. (Although One event can have many attendings?)
Many attendings can belong to many events. (Although many attendings can belong to one event)
I did another diagram using Reverse Engineering from Workbench, and it gave me almost the same. The only difference is that between events and attenders is a one-to-many relationship.
Sometimes I look at them and I am not aware of which question is the best when 2 questions are possible. Is it one too many, or many too many.... This is a tricky question for my brain. It is like there is a missing link that I cannot grasp, and I am pretty sure it is not that hard.
And this is just a simple relationship, don't wanna know the smack my brain would give me if I were to make a 10-20 tables diagram ... Any other criticism is welcomed :) Thank you!
Many users can have one role. (User, Admin, University)
One role can be belong to many users.
One user can have one event.
One event can belong to one user.
One user can have many attendings.
Many attendings can belong to one user.
All of these statements are correct. From my understanding, you're having difficulty describing the relationship between users and events. Essentially what you have is a many-to-many relationship between users and events. In order for a many-to-many relationship to exist in standard relational systems, there must be a join table. The attenders_to table is serving the purpose of a join column in this relationship.
There also appears to be a separate relationship between events and users, in that each event has a direct column for a userId (I imagine this represents the person hosting/putting on the event). This can be seen as almost independent of the other relationship.
So in short, there are actually two relationships between Users and Events: A Many-to-Many relationship describing the people attending the event, as well as a One-to-Many (that is, one User to many Events) relationship describing the host of the event.
Let me know if this helps clear things up or if there's anything else that I'm missing!
I am working on a Project where I have below use case.
User can have many taglines for them , we have lot of predefined data in the DB which we using to show autosuggestion when they started typing tag lines, I am using Rails.
User has_and_belongs_to_many taglines
Tagline has_and_belongs_to_many users
I have separate joint table and everything was fine , but now I need to store custom taglines of user to DB , which will be belongs to only particular user.
Should I clone the taglines table and add user ID to it Or what is the best architecture to handle these kind of scenario , if we have more than one model which have same use case as like taglines.
your existing user and tagline table has many-to-many relationship, keep it that way. Whereas the user table and the new customTagline has a one-to-many relationship so why don't you create a new table to represent it? Since you mentioned the customTagline belongs to only a particular user.
#BroiSatse Comment make sense, I followed same.
If you create a second table, you will need to remember to update two
tables/models every time you will want to change your model. You won;t
be able to pull all the user tags in one go neither. many-to-many is
able to hold one-to-many association. Just add a validation to check
that given tag can belong to only one user if it is custom.
I have three tables: Resumes, Orgs, and Resume2Org. Basically, Resume2Org is my many-to-many relationship table linking Resumes.resume_id to Orgs.org_id (so it only has those two keys in that table).
My question is, is it okay to use that many-to-many relationship table to store other data? My use case: the database is part of a system to sift through incoming resumes. But I've been asked to implement a "marked as read" feature so we can easily get the list of resumes we haven't looked at yet. But since a resume can belong to many different orgs, we only want to mark a resume as read for the org the user/viewer belongs to. I thought, hey, having that flag in Resume2Org would be perfect. Is this a smart approach, or should I create a new table specifically for "marked as read"? All the examples I've seen about many-to-many relationship tables is that those tables are used just for that... linking two tables.
Yes it is okey to have additional fields in a many-to-many table. I think it is the right way to do in your case as you don't need to join additional tables and you save spaces.
I was in a very similar situation last week and I added additional field for that.
I am using Ruby on Rails 3 and MySQL.
In my project I would like to create an activity-stream "module" in order to save each user action information in a dedicated user table. That is, to create a database table for each user.
Is it a good approach to create a database table for each (new registered) user in my application?
No, it is not a good approach. Why would you create a separate tables with all the same fields? Just add user_id to your table and store all info for every user in there.
I do something similar, and it's not necessary to create a whole table for each user. For example, I have a table called "user_actions", and in it there is a column, "user_id".
The relationships are:
User has_many :user_actions
UserAction belongs_to :user
And you're done. Let the foreign-key relationship that comes naturally take care tying the specific action to a specific user.
Once you do that, you only need to decide:
Which actions cause an entry to be added?
How long should you retain the data (1 week, 6 months)?
For example, on my site, I keep a log of the last 5 things a user viewed, and present that list to them on a section of the page called "Recently viewed items" for convenience.
I also have a separate table called "admin_actions" that I use for security logging that keeps track of everything done under an admin account, and what admin account made what sort of change.
I guess the answer is that it depends on how many users there are. If it's not a small, defined number then I'd suggest that it's not a good idea to create one table per user.
I'd suggest a single table with one column being a unique identifier for the user. Make sure that whenever you're querying the table that you're using an index that has this column as the first column in the key. E.g. PRIMARY KEY(user_id, activity_time)
This should allow for fast and efficient reading of the rows.
A new requirement has come into an existing application. Current, we have an organization table, and it has a child table CalendarEvents. Now, the request is to allow either the User table, the Organization table, or the Division table own calendar events. I am thinking something needs to change because right now, this would leave me with creating the following table structure:
Organization (organization_id)
User (user_id, organization_id)
Division (division_id),
Calendar (calendar_id, organization_id, user_id, division_id),
CalendarEvents (calendar_event_id, calendar_id)
I am trying to avoid linking Calendar to multiple parents. Is there are better way to do this that I am missing? (An organization/user/division can have multiple calendars, but only one org/user/division can own a calendar)
Thanks for any input.
Since User instances and Organization instances can have their own events, I'd be inclined to make separate tables:
Organization
OrganizationCalendarEvents (with FK to Organization)
User
UserCalendarEvents (with FK to User)
In this way, the two entities can control their own events. In addition, if you keep the structure the same, you could use a single base class in your middle-tier which can load from either table.
If the CalendarEvents for each entity (User, Organization, and Division) are mutually exclusive, I might start out with three identical tables of events: UserCalendarEvents, OrganizationCalendarEvents, and DivisionCalendarEvents.
A better solution, though, may be to define those as three tables of links:
UserCalendarEvents
user_id
calendar_event_id
OrganizationCalendarEvents
organization_id
calendar_event_id
DivisionCalendarEvents
division_id
calendar_event_id
Yes. There is a technique called "morphing" which is appropriate for your case. Your CalendarEvents table should have a field called "owner_type" and another field called "owner_id". "owner_type" would indicate the table to which "owner_id" is a foreign key for the particular row. If owner_type is 1, then owner_id is a user_id; if owner_type is 2, then owner_id is an organization_id. And so forth.
One table column for many fk tables? .
and
multiple tables need one to many relationship .
If you want the DBMS to enforce the integrity rule that any calendar event is always either for an X, or a Y, or a Z (and just one of them), then you'll have to create three tables.
You can always create a view of "all calendar events" by UNIONing them together (after projecting away the owner column, of course). Obviously, that view is not updatable.
If you set up three separate tables with only a "link" to a "shared" events table, you still won't be guarded from having "orphaned" events.