Struggling to build a mutli-type parent model feature for a project

Need Help
#1

Firstly, apologies for the title of this post - I didn’t know what else to put, but I do think it describes my issue quite well.

So, I’m building something and I’m not sure how I should be approaching it, and still utilise October’s powerful backend list/form features…

I want to have a “Resource” area in the backend and frontend. Resources can be one of many types, for example video, report and case study.

Each “type” will have some unique properties, but they will also share some common properties too such as a title and published_date.

I know there are probably a few ways this could be done.

  1. The easiest would probably be to have just one Resource model, and store all resources in the same table - and only fill the columns that are needed for that particular resource type.

  2. Second option is to have separate models for each resource type, but I think this is going to get a bit dirty when trying to combine everything together into a backend list and trying to use the filter features.

I’m wondering if there’s something I could do with a trait, or a parent model that has a polymorphic relation to each resource type - something like that.

If anyone has any good ideas on how I should approach this I’d really appreciate it.

Thanks

#3

Hey @neil-impelling

Deciding between options 1 and 2 depends on scaling requirements. Most database engineers will say to separate data as much as possible since it helps with large-scale applications. However, it can result in a lot of duplication, both in code and database structure.

I would start with option one and then, as the application scales, have a transition plan to move to option two. Unless you are tasked with building a “world-class application” then start with option two and charge the client accordingly.

#4

I did something similar with a different approach.

First i have a model/table with common details. E.g title, status timestamps, resourceType etc.

Second table consist of meta details with haveMany. This way ensure the scaling and also the meta can be changed accordingly.

1 Like