I'm focusing on a peer lending application which has various kinds customers (ie. debtors, loan companies, sponsors, etc) which have different fields. Furthermore, a few of these customers can fit in with a couple of things (ie. loan companies may also be sponsors). So, is single table inheritance advisable in cases like this? And when so, is one able to user fit in with two groups with just one "type" area? And when STI isn't what you want, what's the easiest method to get it done? In the end, using different tables will need saving exactly the same info to multiple databases, which does not appear efficient.
Thanks ahead of time for just about any help!!
I believe it's safe to visualize that the role of every user is dependent upon the kind of a lease/deal. That's, if there exists a deal
D1 and 2 customers
U2, then its the offer that defines whether
U1 is really a sponsor or perhaps a customer.
Things I suggest would be to leave customers hierarchy being an STI and introduce another class, say
DealUserRole (Deal, User, Role).
You could utilize the jewel I've been focusing on (CITIER) - http://peterhamilton.github.com/citier to complete your inheritance, still in development but presently functioning fine. Much better than STI when the different classes have plenty of unique fields. STI could leave them Null. Plus MTI is much more extensible later down the road. To be sure you should also introduce a job for that customers. However I think by using this you can link it towards the parent (User class) therefore it would affect all subtypes of user.
class User < ActiveRecord::Base has_many :roles end class Role < ActiveRecord::Base acts_as_citier has_many :users end class Borrower < Role acts_as_citier #Other borrower stuff end class Lender < Role acts_as_citier #Other lender stuff end