User model handling two separate database tables

https://laravel.com/docs/5.6/eloquent-relationships

My question is, do I have to create a new separate model "meta_users" and then tie it in with my User model. Or can I just use the User model to work with both tables.

You should create it, then you can just use relationships. You'd create the meta_user model, which can be totally blank (just create with artisan).

Then in the User model, you'd create a relationship to the meta_user model like the docs I linked to show.

Then you could just do User::with('meta_user')->get() which would get the user(s), along with their associated meta_user data.

Hey Cronix, thanks so much for the response.

Bare with me here, so I created a Meta_Users.php model which is completely blank. Then in the User model, I added :

 public function meta_users(){
        return $this->hasOne(Meta_Users::class);
    }

Then I opened PHP artisan tinker

$ash = App\User::find(1);

got the fetch. Then I did $ash->meta_users();

which yielded the 'BadMethodCallException with message 'Call to undefined method Illuminate\Database\Query\Builder::meta_users()'

Could you clarify what you mean with User::with('meta_user')->get()? Did I set up the relationship properly?

EDIT:

I just did

$ash = App\User::with('meta_user')->get(); and got it working. Thanks so much!

The model name should be Meta_user, not Meta_Users, since laravel uses the plural form of the model name to determine the db table to use (unless you specify it in the model).

https://laravel.com/docs/5.6/eloquent#eloquent-model-conventions

/app/Meta_user.php

<?php

namespace App;

use Illuminate\Database\Eloquent\Model;

class Meta_user extends Model
{
    //
}

$ash->meta_users();

If you use it as a method, meta_users(), it will return a query builder instance that you can chain onto. If you want to actually get the data, call it as a property, $ash->meta_users, however, it's an object, so you'd want to call a property on the object, $ash->meta_users->firstname.

But really, I don't see any real reason to have the table separate at all for what you're doing and would put the fields in the users table. It would also save a query.

@BlastedAsh

got it working. Thanks so much!

You're welcome. Please mark the thread as solved if you have it working the way you want. Please do see my last post though about this looking pretty unnecessary for what you're doing and saving a query.

@Cronix One of the reasons I wanted to have a table separate is because in the future i wasn't quite sure if there will be different types of users which may not need some of the fields in the user table (would be difficult to normalize i mean) I also wanted to vertically partition since the users table felt a bit large for me. I did some research and you seem to be right, it doesn't seem necessary so I will remove it. Thanks a ton!

@BlastedAsh It's not a problem to have nullable fields in the db table for things that don't apply to every user type, or are even optional for the user Maybe you have a twitter_url field or something. Not everyone has twitter, so it should be nullable. null doesn't take up any space.