A problem was posed to me that borrowers of loans have cosigners. Therefore, borrowers are people that have cosigners that are people. How would you set up this has-a and is-a relationship in Active Record?
"kesslerdn" <kesslerdn-v+z9hhnkyldeoWH0uzbU5w@public.gmane.org> writes:> A problem was posed to me that borrowers of loans have cosigners. > Therefore, borrowers are people that have cosigners that are people. How > would you set up this has-a and is-a relationship in Active Record?I would make them all People, then in the Loan has_a :borrower, :class => People has_a :cosigner, :class => People -- doug-jGAhs73c5XxeoWH0uzbU5w@public.gmane.org
Just use a parent child relationship in the borrowers table. they are both borrowers, but one is a child of the main borrower. ie: table: Borrowers id parent_id Name etc. If parent_id is NULL then they are a borrower if parent_id is NOT NULL then they are a cosigner Hope this helps Sam On 8/9/05, kesslerdn <kesslerdn-v+z9hhnkyldeoWH0uzbU5w@public.gmane.org> wrote:> A problem was posed to me that borrowers of loans have cosigners. > Therefore, borrowers are people that have cosigners that are people. How > would you set up this has-a and is-a relationship in Active Record? > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
kesslerdn wrote:> A problem was posed to me that borrowers of loans have cosigners. > Therefore, borrowers are people that have cosigners that are people. How > would you set up this has-a and is-a relationship in Active Record?I might be completely off-track with this, but a one way relationship looks easy for this. Something like: class People . end class Borrower < People has_many :cosigners, :class_name => ''People'' end Or that wouldn''t fit your needs? Kristof
This is one example where CLSTI might be a nice choice. There are other approaches, though. As for the database relationship, you might want something like: people ----------- id name ... loans ---------- id name ... roles --------- id title (''borrower'',''cosigner'', etc...) borrowers --------------- id person_id loan_id role_id This way, for a given loan, you can select all associated people from the borrowers table, and you''ll have their role info. This would provide for multiple borrowers and multiple cosigners (and any future roles) for the same loan. The AR relationships should be pretty straight forward for that schema. On Aug 9, 2005, at 10:31 AM, Kristof Jozsa wrote:> kesslerdn wrote: > >> A problem was posed to me that borrowers of loans have cosigners. >> Therefore, borrowers are people that have cosigners that are >> people. How >> would you set up this has-a and is-a relationship in Active Record? >> > > I might be completely off-track with this, but a one way > relationship looks easy for this. Something like: > > class People > . > end > > class Borrower < People > has_many :cosigners, :class_name => ''People'' > > end > > Or that wouldn''t fit your needs? > > Kristof > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Toby Boudreaux said:> This is one example where CLSTI might be a nice choice. There are > other approaches, though. > As for the database relationship, you might want something like:I agree with you, but it may not be necessary to give a borrower an id. Regards, Ed -- Transmogrify, LLC * <http://xmog.com>
On Tue, 9 Aug 2005, Toby Boudreaux wrote:> This is one example where CLSTI might be a nice choice. There are otherWhat is CLSTI? Google doesn''t turn up much that seems relevant, Wikipedia has no entry for it. If this is a stupid question, at least the answer may get archived :-) Thank you Hugh
Yeah, I would make the key a combination of the three fields, but managing the borrowers as objects with Rails seems much simpler if an id field is set. It''s one of those little quirks that isn''t really bad at all, but is just a teeny bit weird. :) On Aug 9, 2005, at 11:23 AM, Ed Watkeys wrote:> > Toby Boudreaux said: > >> This is one example where CLSTI might be a nice choice. There are >> other approaches, though. >> As for the database relationship, you might want something like: >> > > I agree with you, but it may not be necessary to give a borrower an > id. > > Regards, > Ed > > -- > Transmogrify, LLC * <http://xmog.com> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 8/10/05, Toby Boudreaux <rails-lb8SQxIZKShBDgjK7y7TUQ@public.gmane.org> wrote:> This is one example where CLSTI might be a nice choice. There are > other approaches, though.This is not a good choice for inheritance as there may well be cases where an object would have to change type. What about people who are both borrowers and cosigners? People who were borrowers but are now just cosigners. Inheritance doesn''t allow for this ''transmogrification'' so you shouldn''t use inheritance. I''d suggest composition (then again, I always do) class Person < AR::Base has_one :borrower has_one :cosigner end class Borrower < AR::Base belongs_to :person end class Cosigner < AR::Base belongs_to :person. end With 3 tables to persist them, people, borrowers, cosigners. A person who''s both a borrower and a cosigner would have @person.borrower and @person.cosigner. -- Cheers Koz
Yeah, I chose to illustrate the method I did because inheritance would be limiting unless it happened to fit the particular app. I wonder if composition is really best, though, as borrower attributes as well as cosigner attributes might be defined per loan, not per person. I don''t know enough about the way loans work, but I imagine attributes might be factors of a particular transaction/relationship, and not of people? Anyway, in my model, cosigners ARE borrowers -- they''re just a certain type of borrower. class Person < AR::Base has_many :borrowers end class Borrower < AR::Base belongs_to :person belongs_to :loan belongs_to :role end class Loan < AR::Base has_many :borrowers end Adding methods to person to get loans and to loans to get all cosigners, all borrowers and all non-cosigner borrowers would be trivial. Again, though -- I''m basing this on my assumptions of how the real world stuff is structured, and that might be off base. :) On Aug 9, 2005, at 3:50 PM, Michael Koziarski wrote:> On 8/10/05, Toby Boudreaux <rails-lb8SQxIZKShBDgjK7y7TUQ@public.gmane.org> wrote: > >> This is one example where CLSTI might be a nice choice. There are >> other approaches, though. >> > > This is not a good choice for inheritance as there may well be cases > where an object would have to change type. What about people who are > both borrowers and cosigners? People who were borrowers but are now > just cosigners. > > Inheritance doesn''t allow for this ''transmogrification'' so you > shouldn''t use inheritance. I''d suggest composition (then again, I > always do) > > class Person < AR::Base > has_one :borrower > has_one :cosigner > end > class Borrower < AR::Base > belongs_to :person > end > class Cosigner < AR::Base > belongs_to :person. > end > > With 3 tables to persist them, people, borrowers, cosigners. A > person who''s both a borrower and a cosigner would have > @person.borrower and @person.cosigner. > -- > Cheers > > Koz > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Michael Koziarski wrote:> This is not a good choice for inheritance as there may well be cases > where an object would have to change type. What about people who are > both borrowers and cosigners? People who were borrowers but are now > just cosigners. > > Inheritance doesn''t allow for this ''transmogrification'' so you > shouldn''t use inheritance. I''d suggest composition (then again, I > always do)I think composition is usually a safer choice for expressing business components relationships, but on the domain field you should usually go with the solution which is expressing your domain''s logic more naturally. Eric Evans'' Domain Driven Design book (ISBN: 0321125215) helped me a lot understanding this field, I heartly recommend it to anyone doing software design. Kristof
Im going to agree fully with toby here. Michael, your method limits you from having only ONE borrower, or only ONE cosigner, when there can very well my multiple''s of each. and having 3 tables with the same structure is something that you should never have. using toby''s method if anything its easier to do as you described. (removed cosigners, swapping roles around.) what if one person has 2 loans or is borrowing money and cosigning for someone else. this would require multiple records in your setup holding the same exact data and asking for inconsistences to happen. On 8/9/05, Toby Boudreaux <rails-lb8SQxIZKShBDgjK7y7TUQ@public.gmane.org> wrote:> Yeah, I chose to illustrate the method I did because inheritance > would be limiting unless it happened to fit the particular app. I > wonder if composition is really best, though, as borrower attributes > as well as cosigner attributes might be defined per loan, not per > person. I don''t know enough about the way loans work, but I imagine > attributes might be factors of a particular transaction/relationship, > and not of people? > > Anyway, in my model, cosigners ARE borrowers -- they''re just a > certain type of borrower. > > class Person < AR::Base > has_many :borrowers > end > > class Borrower < AR::Base > belongs_to :person > belongs_to :loan > belongs_to :role > end > > class Loan < AR::Base > has_many :borrowers > end > > Adding methods to person to get loans and to loans to get all > cosigners, all borrowers and all non-cosigner borrowers would be > trivial. > > Again, though -- I''m basing this on my assumptions of how the real > world stuff is structured, and that might be off base. > > :) > > > On Aug 9, 2005, at 3:50 PM, Michael Koziarski wrote: > > > On 8/10/05, Toby Boudreaux <rails-lb8SQxIZKShBDgjK7y7TUQ@public.gmane.org> wrote: > > > >> This is one example where CLSTI might be a nice choice. There are > >> other approaches, though. > >> > > > > This is not a good choice for inheritance as there may well be cases > > where an object would have to change type. What about people who are > > both borrowers and cosigners? People who were borrowers but are now > > just cosigners. > > > > Inheritance doesn''t allow for this ''transmogrification'' so you > > shouldn''t use inheritance. I''d suggest composition (then again, I > > always do) > > > > class Person < AR::Base > > has_one :borrower > > has_one :cosigner > > end > > class Borrower < AR::Base > > belongs_to :person > > end > > class Cosigner < AR::Base > > belongs_to :person. > > end > > > > With 3 tables to persist them, people, borrowers, cosigners. A > > person who''s both a borrower and a cosigner would have > > @person.borrower and @person.cosigner. > > -- > > Cheers > > > > Koz > > _______________________________________________ > > Rails mailing list > > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Zachery Hostens <zacheryph-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Michael, > > your method limits you from having only ONE borrower, or only ONE > cosigner, when there can very well my multiple''s of each. and having > 3 tables with the same structure is something that you should never > have.No,> using toby''s method if anything its easier to do as you described. > (removed cosigners, swapping roles around.) > > what if one person has 2 loans or is borrowing money and cosigning for > someone else. this would require multiple records in your setup > holding the same exact data and asking for inconsistences to happen.No. You''ve missed the point of my post. Loans have their relations to Borrowers, to Cosigners, to anything. Whatever the domain requires. One Borrower per person who borrows. One Cosigner per person who cosigns. No duplicated stuff unless cosigner and borrower are the same, in which case just have one class. -- Cheers Koz