Search code examples
laravelinheritanceeloquentmodels

Extending Eloquent Models in Laravel (use different tables)


I’m building a Laravel application that involves tracking different types of leads. For example, there are Refinance leads and Purchase leads.

Since the leads share a lot of information and functionality, but not all, my thinking was to create a Lead class, which extends Laravel’s Model class, and then a RefinanceLead class, which extends the Lead class.

So I’d have:

class Lead extends Model
{
    // shared lead stuff
}

class RefinanceLead extends Lead
{
    // stuff specific to refinance leads
}

My questions are:

  1. Does this strategy make sense?
  2. If it does, how is Eloquent going to handle the data? Will I have a leads table and a refinance_leads table?
  3. Will a new instance of the RefinanceLead class utilize anything in the leads table?

I’ve had trouble answering this question via the documentation, but if I missed where this is explained, please let me know. Thanks.


Solution

  • 1. Yes, it makes perfect sense to have all the common functionality in a parent model.

    2. Basically each Eloquent model will handle the data from its own table defined in the protected $table variable. You can override the parent variable to set a separate table for all the different child models. Laravel Table Names

    For example if you use the getId() method on a RefinanceLead instance it will return the id from refinance_lead table. If you use it on a PurchadeLead instance it will retirn the id from purchade_table

    class Lead extends Model
    {
        public function getId() {
           return $this->id;
        }
    }
    
    class RefinanceLead extends Lead
    {
         protected $table = 'refinance_leads';
    }
    
    class PurchaseLead extends Lead
    {
        protected $table = 'purchase_leads';
    }
    

    3. I don't know what are your exact needs, but in general I'll suggest making the Lead class abstract and so you don't associate a table for it. Use it only to separate common functionality, relations, etc... Of course as it was suggested in the comments, implementing an interface is always a good idea.

    abstract class Lead extends Model implements LeadContract
    {
       // class body
    }