Hello!
I ask for help in explaining the optimal structure of the database.
Specifically, I mean the situation where you need to create recurring entries, such as posts / jobs / events.
For example, here are the instructions for creating a copy of Instagram:
In this instruction, the author creates two types of data:
- Data type: Post - with fields: Likes, Comments, Post-content
- Post-content - with fields: Caption, Post-image
So here
I’m doing a potentially large project - there will be many duplicate entries and many filters to filter them out in repeat groups.
Questions:
- Why does the author use a separate data type for the “content” (Post-content) of the post?
- What do you recommend: use the data type structure like the author of the instruction (Post + Post-content) or make one data type (Post) and add all the necessary fields to it? Why?
Thank you for your attention!
Hey @prollikyy
To answer your questions:
- This is answered in the blog post itself
When creating a database, we recommend splitting larger items into separate data types to enhance the speed of your application.
For example, we’ll create two separate data types for each post. One data type will include the basic details of a story (including the creator, the number of likes, and the total comments), while the other data type will include larger content files like the photo and caption of the post itself.
By creating these as separate data types, it allows us to only load the necessary information when it’s needed, reducing the amount of content the Bubble editor will need to render.
- I think it really depends on your exact use-case to whether you’d copy this. If your app is text heavy and not media heavy, then it’s probably not as much of a concern. However if you’ve got a lot of media (photos, videos, attachments etc), then I think splitting it out for the reasons answered above make sense.
Cheers,
Josh
Josh @ Support Dept
Helping no-code founders get unstuck fast 
save hours, & ship faster with an expert 
on-demand
I post daily about no-code and Bubble on Twitter 
2 Likes
Hello @josh24
Thanks for your reply
- Yes, the author’s manual really describes the reason for the separation of data types. Here’s the thing, let me give you an example:
When creating a feed of publications through a repeating group, the author adds both types of data to the “record cell”:
- “One data type will include the basic details of a story”
- “Other data type will include larger content files like the photo and caption of the post itself”
What was the point in this separation of data types, if both data types are used for publication in the “publication feed”?
Separation of data types would be clear in such a case:
- “One data type will include the basic details of a story” - and these data fields would be visible in the post cell in the “publication feed”;
- “Other data type will include larger content files like the photo and caption of the post itself” - and these data fields would only be visible on the page of the publication itself. These fields would contain videos, pictures and other heavy content.
Separation of data types into Post and Post-content and further use of both data types in repping groups in the “publication feed” creates misunderstanding
The smaller and simpler a table is the faster you’ll be able to search it, and your app will perform better.
If you put everything into the posts table and that table is super heavy, then each time you search that table to pull out the posts you want to show in the repeating group it’ll chug along.
It’ll chug along because there’s a bunch of fields with lots of data in them that relate to posts that you aren’t going to show back to the user.
That’s why it’s better to keep that posts table as light as possible (just text), and then separately pull down the media that you need to support those posts that you end up showing.
Of course if your repeating group search is all happening server side and you’re not using any filtering etc in the browser, you wouldn’t be downloading all of that media client side for the posts you won’t show. But it will still slow down the search on the server itself because the table is heavier.
Josh @ Support Dept
Helping no-code founders get unstuck fast save hours, & ship faster with an expert on-demand
I post daily about no-code and Bubble on Twitter
@josh24
Thank you very much for the detailed answer. These are the details I tried to understand.
The author of the Instagram manual, of course, explains the reasons for the division of databases, but still not convincing enough.
Thank you for your attention!
1 Like
