I think trying to model all those relationships solely in your user models will turn out way more complicated than adding a few extra models to your app to help capture those relationships. Your concerns about data coupling are valid, but at some point, you'll have to store the information about which roles a given user may fullfill, and there's no better place than at the user model itself, on the database, IMO.
In the case of Cars, a Car would belong_to a User, such that the association's foreign key (User id) would be located in the Cars table in your db, and the User tables would not contain that information at all. As for the superuser having a garage_id == null, I don't think that is much of a problem, considering it would be a minority of the Users that would have that role. One other technique you may consider is the use of class inheritance along your User models, for example, Customer < User, Admin < User, etc. This way, certain properties (garage_id, etc.) would be available only in some of the User subclasses. This has the downside of making things a bit more complicated at the db level, and your business logic would likely get more complicated too. Not sure if it would apply to your case, anyway, just wanted to point out that it is also a valid approach. For a first iteration on this problem, personally I would have those roles stored right in the User model (as a String), with methods to test for roles (user.admin?, user.garage_owner?(garage_id), etc., etc. As a side note: design is always about compromise, every design choice has its ups and downs, and it's up to the product designer (you) to weight in on the goods and bads and make the choices, based on what are your requirements, constraints, etc. Your concerns are valid, indeed, it shows you are considering the outcomes of your choices beforehand, which is generally a good thing. At some point, though, you have to make the cut and start experimenting, and seeing how things turn out. Especially when dealing with a business domain (or technology) not fully understood, trying out some of the options might go a long way helping you understand and decide which are best for your case. regards, Paulo On Tue, May 17, 2011 at 12:19, Pingu Penguin <li...@ruby-forum.com> wrote: > Thanks for the reply Paulo, my question was about the business > relationships involved, and I think you went a long a way towards > answering it. > > With regards to a Customer being associated with multiple Garages, good > news, this is not possible, they would have to have separate accounts. > > Your solution is great, but it doesn't address all the problems. How > would I handle a customer having ownership of their car only? Would I > add a car_id to User that would be NULL for all users other than > customers? This makes me uneasy, as the logic about the "roles" each > user can full fill would be spread around. The roles I could apply in > cancan would be restricted by the database data. Does that make sense? > it just seems like cancan, and database would be highly coupled, is it a > valid concern? > > And how do I handle the superuser having ownership of all garages? I > guess they would have a garage_id of NULL? > > Considering that a "Garage" is essentially just a name, I was thinking > that a preferable design would be to somehow model the relationships > between the different types of user directly, but as I couldn't make > that work, I am probably on the wrong track. > > -- > Posted via http://www.ruby-forum.com/. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Talk" group. > To post to this group, send email to rubyonrails-talk@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-talk+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-talk?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
