Good database design in Bubble

databases they freaked me out as well in the beginning if i'm being honest but they are the most important part in my opinion and actually kind of one of the more fun parts when you're building a bubble app configuring your database at the start of a project is a must do it's the way that you're going to figure out the overall structure of your app and build a foundation so the way i like to think about a database is that you're really populating the world right the universe that is your application you're deciding what are the things that are going to exist in the world right you're playing god what are the animals what are the rocks you know what are the plants all of the different categories of things that's what you're doing and when you have that foundation done right then you can invite invite your users into that world and they can play in the world that you've created so um when you're configuring a database there's really two questions to keep in mind the first one is what are the things right or the objects as you might sometimes hear them called that exist right i'm playing god this is the world that i'm creating right what are the things in that world the second one is what are the relationships between these things because of course the things that we're going to define in our database they don't exist in a vacuum right in the case of amazon you have a user and you know they're going to do stuff in that application right they're going to interact with tvs and basketballs and whatever else they might buy credit cards that they're going to purchase stuff with so things don't exist in a vacuum so let's focus on this first question for now though what are the things or the objects that exist it sort of hides a sub question which is defining what is an object right or a thing okay and bubble we call these things but in sort of like the wider programming world we might call these objects so what is an object or a thing versus an attribute right if we look in our bubble database we have this user data type okay so we've got a user that's going to exist more or less in every single app and you notice that it has this email field here okay so that email field isn't a thing unto itself right there is sort of nonsensical to have an email independent of a user just like it's nonsensical to have sort of like a screen size independent of a tv or a color like a color red outside of a wall or a house or a door or whatever okay so you've got to be able to distinguish between what are things and what are attributes so in the case of our user right we've got this email field if we look at amazon again we've got a range of different products here they're all tvs so should we have a tv data type or should we have a a product right like what's the higher level category and the way i like to think about this is is literally that way like what is the highest level category that's relevant for our application in the case of amazon all products are going to be treated the same way right like there isn't a product that has some kind of special status that isn't going to be added to a cart and paid for and delivered they're all they're all the same in essence but underneath products okay you have sort of different types of products just like if we were playing god to use that title metaphor again if i'm creating animals in my world like there's a huge variety of different animals there's different categories of animals right i've got mammals reptiles i've got fish right i'm not using the scientific names here obviously but it's the same concept when you're talking about defining the things that exist in your database so what i would actually do is i would have a product thing okay and then i would have something like a category field okay and that might be a tv okay and that might be sort of sports equipment okay and you can you know obviously get a lot more granular here and i might have a name field okay which is going to correspond to like the actual name of the tv like this tcl inch blah blah blah so that's the idea between distinguishing between attributes and things so let's keep going through here let's say i'm going to purchase this tv and it looks like i've already added it to my cart okay so it looks like we're creating a relationship here okay like this tv is being added to my cart as a user okay so two ways we might go about this okay we might have a field on this user right called a cart and that might be a list of products let's say right like this just like this can just be populated by you know products left right and center here's another product right and that goes into this cart okay so that's one way that we could create this relationship between a user's items a product that they've added to their cart and the products themselves but there's another way that we could do this and that's actually to have a separate cart thing whereas which is actually where we're going to send these products into now why would you have one rather than the other this is kind of another problem related to with when to define attributes or fields versus when to define an entirely new object to capture some kind of information the way i like to think about it is is there any other information about this thing right and in this context we're talking about a cart is there any other information about a cart that we might like to capture apart from the products that are in it right is there does that have more than one attribute i think there's a good argument to be made that in this case that it does okay because as well as obviously the products that are going to exist inside of that card i think that we also want to keep track of when this car was created okay so the created date okay we might also want to keep track of like the related payment that's an object that we don't have yet in our database but i can i'm thinking through this you know at some point i'm going to go and i'm going to check out and you know there's going to be like a charge associated with that so like there might be like a payment amount here i think that you know as we go about building our database and this is gonna you know the same situation that you run into is you're going to discover that there's more information that you might want to capture about the behavior or the actions that your user are taking and while we might not be able to think of them all right now i think that a cart because it's such a central part of the experience of buying objects within the amazon website this is a good argument to be made that creating a separate cart thing in our database is going to give us a lot more flexibility later on so i want to create that as a separate cart object now if i'm going to proceed to my checkout right so the next step in the checkout process is to select a shipping address okay so this is again i think a scenario we want to create a separate thing or a separate object because like there's multiple addresses that a user can have an address has at least two two fields okay if we've got this address here an address has first and foremost like the address itself okay which in bubble you have this data type thing called a geographic address which we can use for this address we also probably want to track whether it is like the primary address or like the default address which might be a yes or a no field right a boolean type field okay so there's at least two things that we're going to track here so definitely we want to have a separate address and coming back to this what are the relationships between these things question okay it's quite obvious i think that an address is only useful in the context of a particular user okay so we might have my paper is getting a little bit uh crowded here we might have a list of addresses right that's a list okay and that's going to point to you know all of the various addresses that we might have in our database okay so i'm going to stop there i'm not going to go through the whole process but like let's just put that in bubble let's just see what that actually looks like inside of bubble right what i would do first is create the objects right so i'm doing an inventory of my app universe essentially so we've got a product and actually when i'm creating data types i like to have them capitalized so we've got products we have got a cart type thing we know that we have also an address okay and then we might define the types of fields that we have okay so we already said that for our product right that's going to have a name okay and that might be a text type field right it might also have a category right that's going to help with searching and in fact a category is something that we don't have defined but this is a good use case for option sets and uh if you're not familiar with option sets um just let me know in the comments and i'll make a separate video on option sets in short an option set is just a way of defining some data some data that you can reference in your application but it doesn't actually live in the database it's stuff that is going to be static that's not going to change that's not going to be information that you're going to be populating dynamically through the behavior of users and other workflows right you're just going to define it up front and then you're going to be able to reference it throughout your application so we might have a category option set okay and then we we as sort of like the god the creator of this application we're gonna add in some options so like we might have televisions okay we might have sports equipment right you just you'd populate this with all of the categories that you have in your database and the nice thing is that now when we go to define a category field here on the product thing okay we can actually reference that category option set that we just created and maybe we want we can even give it multiple categories by selecting that this field is a list but in this case we won't do that okay obviously our product is going to have a lot more details here right it's going to have a price but this is just to demonstrate like the basic principle so we won't populate this entire object okay then we've got a cart so i can't i think quite understandably is going to have a list of products in it okay so we're going to come down we're going to choose product and we're going to say that this field is a list so whenever you're creating a relationship between two data types okay one thing to keep in mind is the direction of the relationship that you're creating okay in this case we've got right a user okay we've got a cart now a user is only going to have one cart at a time so this can be pretty self-explanatory okay and because only logged in users are going to be able to create carts i.e there's always going to be a user logged in when a cart is created this creator field is automatically going to be populated by that user so we're going to have the reverse connection as well but i kind of skimmed over this list of products on a card okay that's something a little bit different right we've got a cart and we've got products products there's another product it should just be a single product there's another product okay and they are all living inside this carts list of products okay now why do it this way and why not have you know a product product and each product has a list of carts of which it is apart right so then it has a card over here a card over here a card over here right why not do it that way right in this case what i'm thinking about is how do i keep the list as small as it needs to be okay it's unlikely that a cart is going to have thousands upon thousands of products in it okay like in very likelihood like a cart is gonna stay relatively small you know maybe 10 items at the most in this scenario okay if we linked a cart as a list living inside of the product well this list has the potential to get very very large indeed okay like all of the people that are buying you know this particular brand of basketball or iphone or whatever right that list of cards that's going to exist on that product is going to get massive there's going to be a cart for each user that is buying an iphone at that time so that list could get potentially very very very large and the problem with this approach is that because we are anchoring the relationship on these products rather than anchoring it on this cart is that when we're going to want to retrieve all of the products in a particular cart okay what we're going to have to do right is we're going to have to do a search and i'll do this and i'll do this in the app so you can see okay we've got a product and we've got carts there and there's gonna be a list of carts okay so every time that we want to find all of the products that belong to a particular cart right we're going to have to do a search for all of the products okay and then see that the carts field contains some cart object right like this might be like the user's current cart or something like that so we're searching through the entire database of products right which could be you know millions of items just to pull out a few entries that belong to the current user so it's a massively inefficient way of searching okay we want to be searching through the smallest list that we possibly can that's why this approach is much better because we've already got the current user okay who's like accessible all the time right like if you just go into the application and if i clear this like i can grab the current uses whatever okay and if i define a field here on the user called a cart well now all i have to do is i have to grab the current user's cart and then just grab all of the products in that cart which is going to be a relatively small list okay so we're going from the current user grabbing their cart and then retrieving the list of products living in that cart so it's a relatively small list that we're searching through way more efficient in terms of the time that our application needs in order to retrieve those items from the database now the one disclaimer that i'm going to make to this is that if this list of things on an object has the potential to be like infinite right like if we were thinking like we've got a user and a user has like messages right like this is like a chat app like facebook messenger or something i'm saying messages these are all messages right okay this list could potentially go on forever okay in this case it's actually better instead of having a list of messages living on the user you want to just have on each message a field pointing to the user okay so you'll actually do a search through the whole database and then pull out all of the messages that are connected to a particular user that's actually more efficient in terms of the amount of time that it takes to do that search than grabbing a list of things on a particular user on a particular thing and pulling them out if that list is really large and that's something that bubbled themselves have pointed out in their documentation i'll include a link below for you to look at that yourself okay the last thing in our database here was this address thing okay and now we're faced with a similar dilemma right like we've got an address we've got a user okay we know there's going to be multiple addresses connected to the same user right do we have a list of addresses living on the user or does each address point independently to the user okay so you always got to think about this in terms of like where are you anchoring the search to you want to anchor it to the place where there's like minimal searching going on in this case right this list is going to be relatively short in which case it's okay and it's actually preferable for us to have a list of address addresses living on the user okay that's going to be faster okay by you know at a minuscule amount but nonetheless it's a good practice to get into because when your app scales right when you're going to have many many users many many objects in your database these kind of performance optimizations are going to be really important okay so it's better to have this what would you call a one to many connection when the list of many things right this these addresses here is going to be relatively short okay if that list was going to be really really long like if we'd imagine that a user could have thousands of addresses okay then it would be better for us to have a field user living on the address so we're pointing from the address to the user okay but in our case we know that you know a user is going to have a minimal amount of addresses probably going to be in the single digits so this one to many connection is okay all right so those are some things to keep in mind when you are configuring your database really important step that you should be doing at the start of your builds of course you can tweak and optimize your database as you go along but you want to get that foundation right from the beginning so hope that was helpful i plan to be making a lot more videos like this so if there's particular topics that you'd like me to cover let me know in the old comments below see you later

Channel: Matt Neary

Views: 3,659

Keywords: bubble.io, bubble.is, no code, nocode, no-code

Id: CJjN84YESJE

Length: 21min 34sec (1294 seconds)

Published: Mon May 10 2021