Hello everyone…
I have a Datatype of over 50 fields. (some of them are lists)
I’m using a Repeating Group to call some of these fields.
So I created another Datatype that contains only 10 fields of 50.
Should I reference Datatype 50 to Datatype 10? (which I’m doing now but the result is not displayed when I perform a do search) or should I populate those from the beginning?
Thanks
Fabian
Yes, you should reference. For example, your Datatype 10 can have a field parent DT with type = Datatype 50
Yes. If you’ve already created some things prior to managing connections between data types - you need to update old items manually or via WF.
So I have to populate the small ones (datatype 10) and connect them as a reference to the big one (main datatype 50)?
I thought it works vice versa. To populate the big ones and deliver the content to the smaller ones.
It all depends on how do you handle your connections and how do you create things.
For example, you need to create a new Datatype 50 and a satellite Datatype 10.
This is how your WF can look like:
what do you mean by vice versa?
Like filling the Datatype 10 or Datatype 5 etc… and referencing them to one Database (all 50 fields will be displayed here)?
I’m building a vehicle app that will contain all vehicles specification.
When the user performs a search I want it to be light on the Repeating Group… I want to display only a few of them… (because Bubble load all the data even if you are displaying a few of them).
And I thought to use Data Satellite.
But I’m not setting it right apparently.
Thanks again.
Fabian
In the Datatype 10 data type, what does the field parent DT get populated with?
This concept of data satellites is really useful. I think it originates from @petter 's book - which I highly recommend. Really thorough and detailed.
One thing I am struggling to wrap my head around is whether there is ever any duplicated data fields between a data type and its satellite. Even simple lightweight structured data fields like a “name”
Take the example in the book - when we want to create a booking.com type app with the following type of search functionality:
Initially the book describes creating one datatype container for geographies (e.g continent, country, destination) and one for points of interest (hotels and restaurants). These data containers contain the bulk of the information - images and unstructured data.
So far so good - this is intuitive and makes sense. We can use these containers to hold “heavier” data (images and longer descriptions) and we group data concepts with similar information into a single container (e.g geography and points of interest) respectively and identify them within their containers through options sets (continent, country, destination vs hotel, restaurant)
However when it comes to actually creating the search functionality we don’t necessarily want to reference the data type containers as they hold images and unstructured data. Instead, the book suggests creating a separate lightweight search/satellite data type - so as in the image above this might contain whether it is a hotel, restaurant, continent, country or destination and then an identifying name (Dubai, Shangrila etc)
So my question after that long-winded setup is:
do we want to include the identifying name (i.e the name of the restaurant, the name of the country etc) on both the container datatype and the search/satellite data type?
Instinctively I would say no - just pick the datatype where it is most appropriate - in this case the search/satellite. If we created a hotel page we will predominantly bring in data from the container data type. Of course we will also need to know the hotel name but presumably we can just reference the hotel name as a sub thing. So something like hotel container’s search data’s name. As the search data type is lightweight and we are only searching one row I don’t think this would have noticeable performance issues. (We wouldn’t want to reference it the other way for something else as that would mean downloading all the data stored on the container datatype - but for this way around it seems ok)
However later on, the book adds a paragraph on synching data between different data types. So in this case, if we changed the name of the hotel in the container data type it talks about creating a backend trigger to update the name of the hotel in the search/satellite data type. This seems to imply that the name of the hotel is being stored on both the container data type and the search/satellite data type.
If that is the correct understanding does maintaining these dual data fields potentially have WU implications for the app (not to mention added complexity to track)
I appreciate there may not be a black and white answer to this but would appreciate @petter or anyone’s thoughts.
Hi Steven,
My app is at the point where I’m considering approaching prospective clients with a preview however after building up a few thousand records of test data I’ve started to see a perceivable slowing of the response time.
I’ve stripped every possible formula & condition off the main repeating groups which has made a noticeable difference & of course started down the path (all but belated) of database design efficiency & inevitably came across Petter’s work & now your thread.
I was wondering exactly the same thing in relation to duplicated data & exactly how these guys are setting these satellites up & maintaining the data integrity/synchronicity.
My belief was that this was why we build relationships between tables in a relational database, so that we can pull specific fields of data as needed to present in different formats rather than replicate that information at every instance.
But of course, now it appears Bubble pulls the entire related table (beggars belief), hobbling performance by inversely increasing work load & data costs.
I was curious to know where your search led you & what the outcome was? Any & all information greatly appreciated.
Alex.
