Creating a table just to store status text doesn't seem right to me, you could use accessors & mutators to translate between status code and status text.

But I don't know how your app uses (or will use) statuses, so let's say, you do indeed need a separate table for it.

Your model relationships will look a bit different:

class Project extends Model
{

    /**
     * A project can be in one status at a time
     */
    public function status()
    {
        return $this->belongsTo('App\ProjectStatus', 'status_id');
    }
}

class Status extends Model {

    public function projects()
    {
        return $this->hasMany('App\Project');
    }

}

Project belongsTo Status sounds weird, but it's what you should use. hasOne relationship assumes the "child object" (Status in your case) will have a foreign key linking it to its parent (Project), and in your case it's the other way around.

Thanks Xum for your response. I am actually using the statuses table in order to:

• Avoid hardcoding the text in the model itself when using accessor and mutator.
• Avoid hardcoding the status in the html dropdown list
• Easier statuses maintenance by the tool's administrator. He/She will be able to add/modify/delete as needed

Is there any better way of doing this?

Yep, considering the third point, I'd go with tables too.