madsem's avatar

Confusion about naming & relationships for models with same name but different structure/use case

Hello fellow Laracaster's :)

I'm banging my head a little on this one, and hope you can give me some pointers.

Trying to come up with names and proper relationships for models that will have a different use case in my app, but have the same names.

There are two distinctions: Platforms & Networks Each represent a different use case in my app, and consist of multiple child models.

What I have:

Platforms:

  • Platform
  • Customer
  • Account

Networks:

  • Network
  • Account

Now the Account model for each of these use cases, will share just a few column names like name and email, the rest will be completely different, even though they practically represent the same thing (A user/customer owning an account)...

For example the Account model for a Platform will have a column tracking_uuid, and is involved in tracking visitors on websites, while the Network Account model won't have this column and will simply be used to label statistics.

The more I plan relationships now, the more I realize that down the line there will be a lot of confusion with method names, table names and so forth.

Now I've tried multiple things, from moving them into their own namespaces like App\Models\Platforms\Account to trying to prefix all models with either Platform or Network, but in the end the column names of database migrations get simply too long, it becomes messy and ultimately a little confusing.

Now I was thinking if using polymorphic relationships might be the solution, but I'm unsure where I would then move the columns to that are different in each model, and if doing that might get me into trouble down the line somewhere.

Any pointers/ideas how I could improve this?

PS: might be a good idea to also mention the relationships... :)

  • Platform can have many Customer who can own many Account.
  • Network can have many Account

For a Network, the Account model is basically the user/customer, while a Platform has Customers which own Accounts

0 likes
3 replies
bobbybouwmann's avatar
Level 88

I would personally go with a separate table since they have a completely different meaning and data. But I also understand that it gets messy.

Another solution is just keeping all the extra columns as nullable columns. Your database can easily handle all these extra columns and it would all work just fine. Internally, you could work with a DTO or Resources to keep your data a bit more structured.

In the end, I think you're trying to combine two different applications or domains in one. This is never going to be easy to solve. You always have to make a sacrifice somewhere.

2 likes
madsem's avatar

Thanks @bobbybouwmann, you've hit the nail on the head. What you said makes a lot of sense!

Gives me actually confidence in my latest decision to prefix all models with their domain, ie:

App\Models\Platforms:

  • Platform
  • PlatformCustomer
  • PlatformAccount
  • Platform...

App\Models\Networks:

  • Network
  • NetworkAccount
  • Network...

Then instead of following Laravel's convention for foreign keys, I will leave out the prefix there and set the foreign key names inside each relationship method.

This will result in long model names, but ultimately it might also be nice for auto-suggest in PhpStorm etc. You always get everything related to one domain immediately when typing plat...

Please or to participate in this conversation.