Mastering Database Building in Bubble.io: Insider Tips from JJ Englert and Petter Amlie

Подписаться 2,2 тыс.

Просмотров 5 тыс.

50% 1

In this video, JJ Englert and Petter Amlie will teach you the basics of database building in Bubble.io.
JJ's Courses:
Professional Product: nocodealliance...
Professional Databases: nocodealliance...
Professional Workflows: nocodealliance...
Or, if you'd like JJ to conduct a technical audit of your Bubble application, you can book it here: nocodealliance...
Petter's Resources:
Twitter: / amliesolutions
Database Book: www.amliesolut...
Timeline notes provided by @shankarprasad9611 -
03:00 - User Details & User Roles
JJ’s preference for naming Option Sets
05:10 - Discussion on Satellite Datatypes (expanded user details)
ease of setting up privacy rules
Workload Units impact
Performance impact
Common Mistakes
13:00 - Satellite Datatypes - Thinking from User Story perspective (Petter) & structuring DB based on requirements ##
14:35 - What kind of data Bubble loads on page in reference to Satellite Datatypes?
15:10 - Having 2-way relationship on Satellite datatypes + benefits
16:20 - great points by JJ & Petter on DB structuring & User Experience ##
18:00 - QnA - How many fields to use on satellite datatype? Any limit preferences?
20:20 - Having a List of fields on User DB + impact in different scenarios ##
Keep User datatype light
21:20 - Petter: try to hide unique IDs if you can
21:45 - QnA - “View” of datatype feature from Bubble(upcoming) + its impact on Satellite datatypes
23:30 - Restaurant Listings DB
Delivery Times - Option Set (if predefined)
JJ preference for naming yes/no field
26:00 - Great point by Petter on using App Text - if you are building for International Users ##
27:05 - Restaurant - List of Food Categories (BURGER, FAST FOOD) - Petter’s thought process ##
datatype vs Option sets?
Things to think about + Questions to ask yourself
Will that list change over time?
When to have it dynamic or static?
Performance issues
Flexibility over long term + Maintenance workload
Issue with having this as Option Sets
31:30 - Restaurant - Reviews
How to structure Review DB?
Detailed explanation on using static fields instead of calculating avg review on each cell on every page load (WU intensive)
33:50 - Restaurant specific data
Petter’s thought process on having a satellite data type
37:45 - JJ’s preference of deleting stuff
40:00 - User - Favorite Restaurants Feature ##
“list of items” field - when to have it?
QnA - Why store these in User DB instead of User_expanded DB?
44:00 - Food Categories on top filters
44:45 - Storing User address
Why have it on User DB?
Preference of formatting and storing the address?
Geoaddress extract functionality
46:50 - Menu Item Addons
51:30 - Menu Reviews & Restaurant Reviews ##
Interesting points mentioned by both Petter & JJ
When to use lists and when not to?
56:40 - Updating the Review scores (frequency of updating these items)
WUs impact
BWF: Workaround mentioned by Petter using yes/no field on restaurants [58:20] ##
59:20 - QnA - Any specific reasons for using Lists? ##
01:01:35 - Cart Functionality
01:03:45 -JJ: Adding specific attributes that helps product sales funnels ##
01:06:35 - QnA

Опубликовано:

7 окт 2024

Ссылка:

Скачать:

Готовим ссылку...

Добавить в:

Мой плейлист

Посмотреть позже

Комментарии : 33

@shankarprasad9611 Год назад

Loved the session...Thanks for sharing your thought process on structuring databases JJ and Petter 🙏 Anyone who wants to revisit this video, here are some timestamps that can help you quickly access particular topic/discussion: 03:00 - User Details & User Roles * JJ’s preference for naming Option Sets 05:10 - Discussion on Satellite Datatypes (expanded user details) * ease of setting up privacy rules * Workload Units impact * Performance impact * Common Mistakes 13:00 - Satellite Datatypes - Thinking from User Story perspective (Petter) & structuring DB based on requirements ## 14:35 - What kind of data Bubble loads on page in reference to Satellite Datatypes? 15:10 - Having 2-way relationship on Satellite datatypes + benefits 16:20 - great points by JJ & Petter on DB structuring & User Experience ## 18:00 - QnA - How many fields to use on satellite datatype? Any limit preferences? 20:20 - Having a List of fields on User DB + impact in different scenarios ## - Keep User datatype light 21:20 - Petter: try to hide unique IDs if you can 21:45 - QnA - “View” of datatype feature from Bubble(upcoming) + its impact on Satellite datatypes 23:30 - Restaurant Listings DB Delivery Times - Option Set (if predefined) JJ preference for naming yes/no field 26:00 - Great point by Petter on using App Text - if you are building for International Users ## 27:05 - Restaurant - List of Food Categories (BURGER, FAST FOOD) - Petter’s thought process ## * datatype vs Option sets? * Things to think about + Questions to ask yourself * Will that list change over time? * When to have it dynamic or static? * Performance issues * Flexibility over long term + Maintenance workload * Issue with having this as Option Sets 31:30 - Restaurant - Reviews * How to structure Review DB? * Detailed explanation on using static fields instead of calculating avg review on each cell on every page load (WU intensive) 33:50 - Restaurant specific data * Petter’s thought process on having a satellite data type 37:45 - JJ’s preference of deleting stuff 40:00 - User - Favorite Restaurants Feature ## * “list of items” field - when to have it? * QnA - Why store these in User DB instead of User_expanded DB? 44:00 - Food Categories on top filters 44:45 - Storing User address * Why have it on User DB? * Preference of formatting and storing the address? * Geoaddress extract functionality 46:50 - Menu Item Addons 51:30 - Menu Reviews & Restaurant Reviews ## * Interesting points mentioned by both Petter & JJ * When to use lists and when not to? 56:40 - Updating the Review scores (frequency of updating these items) * WUs impact * BWF: Workaround mentioned by Petter using yes/no field on restaurants [58:20] ## 59:20 - QnA - Any specific reasons for using Lists? ## 01:01:35 - Cart Functionality 01:03:45 -JJ: Adding specific attributes that helps product sales funnels ## 01:06:35 - QnA

@nocodealliance Год назад

This is amazing! Thank you!

@n0c0de Год назад

Thank you @shankarprasad9611

@baskaranm5385 Год назад

Great session guys! Thank you both!

@nocodealliance Год назад

Thanks for attending!

@SilentMiniTravel Год назад

Loving this content, building while listening to this.

@nocodealliance Год назад

Super glad to hear that!! Thanks for sharing.

@DanFarfan Год назад

Excellent. Thanks for sharing. I'm glad you made the point that number of fields is not the unit of work to care about. It's time (when the info is needed) and size ( e.g. number for activity_count vs files for image_gallery :-O )

@fedorvinohradov392 Год назад

Thank you, guys! This livestream has been incredibly informative and valuable.

@nocodealliance Год назад

Love to hear it. Thanks for letting us know!

@DanFarfan Год назад

Also, free delivery is not a yes/no. base_deliver_price might be zero, aka free. But more important than that, delivery is a base price within a certain distance (aka base_delivery_range). Which is to say, you need to support at least 1 extended range, extended delivery fee as well as out_of_range_distance. Which is to say the location of the restaurant matters a great deal in the Restaurant type (aka object, aka table). Which raises the design question... does each location of this restaurant offer the exact same menu for the exact same prices? Before you answer, that's a trick question. Doesn't matter if they do, because the objective (aka glorious purpose) of the database is to model the real world. Which means supporting a certain location being OUT of a certain Menu_Item or Item_Add_On... because that's what happens in real life. Whoops. Missed all of that too. Which is to say that a Customer is not Ordering from a Restaurant, they are Ordering from a Restaurant_Location -- which even has their own hours of operation and begin_order_time and end_order_time per each day_of_the_week. Fun stuff. :-)

@backstage-caiocalderari Год назад

Very cool guys! 👏

@nocodealliance Год назад

Thank you!!!

@jordyjeppesen 7 месяцев назад

Does truncating a long 2000 character text to a 40 character text reduce work load units by stopping the loading of the entire 2000 characters?

@nocodealliance 7 месяцев назад

No, it happens on the client side and still loads all the text.

@learningstuff5679 Год назад

Any chance we can get a VIEW ONLY share of the Figma file?

@thatQiao Год назад

Yo JJ next time 1080P+ please!

@nocodealliance Год назад

I thought it was already! I’ll look into it

@nocodealliance Год назад

Got that 1080p for Gregs!

@DanFarfan Год назад

Honestly, no one reasonable will begrudge the fact that in little over an hour an entire (serious) application database isn't COMPLETELY fleshed out. However, stone cold errors are avoidable. Perhaps a "Part 2" video does some clean up and extends. Cheers!

@mikyonmars Год назад

No one needs a part 2, we're all aware that certain things were missed and not exactly perfect. If we were building our own restaurant app those simple things would be immediately addressed. Your 3 long comments pointing out simple things and then over-explaining them are totally irrelevant and a whole video explaining them would be awful.

@john13285 Год назад

why repeat the same field on both parent and satellite? wouldn't be enough to have "name" field ONLY on the restaurant parent and not on the satellite as well?

@nocodealliance Год назад

Cause by leaving the name field off the satellite that means you need to load the parent and its data to get the name, which is what you don’t want to do

@john13285 Год назад

@@nocodealliance i see. lets say the parent is the lightweight that is fetched on the search page with potentially thousands of restaurants and the satellite is the more heavyweight that is reserved to be loaded one at a time on the "more info" page. My question is, what is the difference between having all the fields on the parent duplicated on the satellite that are downloaded on page load anyway vs going satellite's parent's field X (name, for example)? Or even going parent's satellite's field X (assuming that the type of content of the more info page is of type parent)? I am trying to understand the benefit of accessing the name from the satellite vs from the parent.

@john13285 Год назад

Why wouldnt i want to load the parent and its data when in the alternative case i already have all the parents data on the satellite? Isnt that the same in terms of download size?

@nocodealliance Год назад

@@john13285 with the parent on the satellite, you’re only loading the UID which is around 32 bytes. But if you load the parent, then it will load all fields (and lists) on the parent which is much heavier.

@nocodealliance Год назад

@@john13285 you might want to take my database course for much more content and education on this topic

@DanFarfan Год назад

Well, shucks. You blew the Cart. A Cart does not contain a collection of Menu_Items, it contains a collection of Order_Menu_Items. It's this person's specific configuration of the Menu_Item that they are ordering (aka buying). The way you have it, every person buys every add_on for every Menu_Item. Whoops. Think of it this way to understand what you missed. Think old school for a minute. When the waitress comes to the table, she writes down your CHOICES on her order pad, which is given to the cook... that eventually becomes the check that you pay. Which is to say, you missed the Order type (aka object, aka table). Cart hasa (1..n) Orders. Order hasa (1..n) Selected_Menu_items for base_price plus (1..n) selected_add_ons for add_on_price. If that's not clear enough for some, think of it this way... customer wants Menu_Item called Meatball Sandwich. They aren't removing that item from the menu by buying it! It's still a Menu_Item that other people can ORDER. :-)