0

My app will be a database of players. That's the core data point of the database. Players (aka...the profiles of players) are what users will login to view/edit/update/delete.

Think of it like a recruiting database, where I (as a recruiter) can login to see the types of players I want to recruit to my team.

So what I am struggling with is how to model the User relationships. Here are the business rules.

  • Each player should be able to login to update their own profile.
  • Each player does NOT have to have a User account, but they CAN if they want.
  • Each player has attributes that a normal 'User' record doesn't have (e.g. an avatar, academic results, a video, etc.).
  • Each coach can login to view all the profiles of the players.
  • Each coach should be able to add other coaches/recruiters to their account.
  • Each admin should be able to CRUD players

This is where it is tricky...a player should just be another Model...because they are the central record for the entire app (like an image may be on an image-sharing site). Where it gets tricky is that each player can be associated with a user record, but doesn't HAVE to be.

What would the associations look like? What would be just a role of the User class and what would be an association with another model?

marcamillion
  • 32,933
  • 55
  • 189
  • 380
  • `User has_one :profile`? – BroiSatse Nov 08 '15 at 16:45
  • I was thinking that...but....remember that a `user` can be a `coach` or `admin`. In that case, they won't need a `profile`. – marcamillion Nov 08 '15 at 16:50
  • I think you're confusing db design problem with app design/usability/whatever problem. Obviously some players will be created before respective users ever join the site so there has to be a way to "claim" the profile. Here you'll have to step up to make sure a person who claims the profile (so real world person wanting to connect to their preexisting profile) is who they say they are. This is again not a db design problem. – Mike Szyndel Nov 08 '15 at 18:26

0 Answers0