How to efficiently setup relations

General
1

I understand that bulk relations update is not possible by reading other topics in this area and have watched some of Mark’s videos regarding the best practice around this topic. However, I would love some input into my particular setup.

I have 4 tables:

  • Jobs
  • Agencies
  • Clients
  • Workers

One job relates to 1 agency, 1 client & 1 worker.

I have a requirement to be able to bulk add 50+ jobs in one go, where they are all from the same agency + client (i.e. workers relations will be left blank for now).

Approach 1
Jobs is “parent” with relations to agencies, clients, workers

However, this approach will mean that when I add 50 jobs, I will need to do the following:

  • 50 deepsave or transactions API call, one for each job.

Approach 2
Agencies, Clients and Workers tables has a relation column pointing to Jobs

When adding 50 jobs, I will do the following:

  • 1 x Bulk Create for Jobs
  • 1 x Add relations in Agencies
  • 1 x Add relations in Clients
  • 1 x Add relations in Workers

Can I ask what’s best practice between approach 1 & 2? Approach 2 seems more optimal if users often add 5+ jobs in one go. However, in the 1:N relations column in Agencies, Clients and Workers pointing to Jobs, it will then have 1000s of relations.

Is there any performance considerations, or any other considerations that would say Approach 1 is more optimal?

Many thanks in advanced!

2

Hi Bob,

How frequently does it happen when you need to import 50+ jobs at once? I was going to suggest creating CSV files and uploading them using Backendless data import (in console).

Regards,
Mark

3

It’s part of the app experience that users can bulk create jobs and they will do so frequently.

4

Hi @Bob_Leung,

It is better to chose approach which matches way in which you work with data in your app.
Situation when there are 1000s of relations in one object may create problems later, when you need to work with those relations. You may save API calls during creation of data but later you may require more API calls to work with it.
It all depends on scenarios in your business logic and it is very hard for me to give you specific suggestions about which approach is better.

Regards, Andriy

5

Hi @Andriy_Konoz - that’s great advice.

For those who might read this in future, I’ve decided to keep to storing all the relations on Jobs and just iterate through.

The reason is because users will later amend these relations on a job by job basis, and it’ll be a lot easier then to “set” new relations rather than trying to find them in 3 different tables later.