New normalized structure limitations
The structure of legacy custom objects was more like a denormalized or NoSQL data structure as child objects and arrays could be stored in the data as object fields. This reduced the number of objects required and records.
The structure of custom objects 2.0 is more like a normalized database and will require more objects and more records to store the same data. While testing I identified the need to split one object into 3.
This impacts the number of API calls required. Is there a way to fetch related records at the same time or fetch related records via the API ?
Example: Object A and Object B with lookup to Object A. Knowing Object A Id how do I fetch all of Object B which lookup to Object A
-
Agreed, this would be important. Being able to have a flag for ?include_relations or similar would make working with custom data much easier and gentler on our APIs.
-
Totally valid concern. However, we've had some performance concerns in the past from sideloading APIs.. I am looking into it right now and seeing if we can alleviate some of these concerns. If not, let me see if we can build an alternate medium term option.. Will keep you posted.
Please sign in to leave a comment.
2 Comments