Database structure
Last updated
Last updated
Now that you have decided on the features you want in your app, it's time to start thinking about how you structure your data. We won't go into the technical details on how to set that up just yet, but keep focusing on the planning stage.
We also have a long list of guides that go into detail on how to plan a database structure for a specific app category (like a project management app, marketplace app or blog). You can use this as inspiration for your project and learn how experienced Bubble developers think:
Article series: Database structure by app type
When you plan your database structure, you should take notes. There are a range of different ways to do this, and there's really no "best practice". You should use whatever method makes sense to you.
For many users, simply noting things down with pen and paper or on a whiteboard is the most efficient way, at least for the first planning stage. You can also consider apps that focus on whiteboarding and diagrams, such as Miro and Lucid.app.
Don't worry about taking notes in the "right" way: your goal is simply to get an understanding of what kind of data you want to store before you start building.
The make up the overarching types of data that you want to store in your app. Let's look at some examples to illustrate:
Social media app (see our detailed guide here)
Users
Posts
Interests
Project management app (see our detailed guide here)
Users
Projects
Tasks
eCommerce app (see our detailed guide here)
Users
Products
These are of course not exhaustive lists, but serve as examples to show what a data type is. Think about the vision you have for your app, and try to plan out what kind of data you need to store to make it a helpful tool.
The are the data that you store in each data type. Fields can consist of different types of data, such as text, numbers, files, images and dates.
Let's repeat the examples from above and add some fields to those data types:
Social media app (see our detailed guide here)
Users
Name (text)
Date of birth (date)
Profile pic (image)
Posts
Header
Content
Interests
Name
Project management app (see our detailed guide here)
Users
Name (text)
Profile pic (image)
Projects
Project name (text)
Project description (text)
Tasks
Task name (text)
Task description (text)
Deadline (date)
eCommerce app (see our detailed guide here)
Users
Name (text)
Address (address)
Products
Header (text)
Description (text)
Image (image)
Price (number)
Shopping cart
Bubble's database is what's called a relational database. Relational simply means that different kinds of data can be connected somehow. For example, in a social media app, a post is connected to a user – that is, it "belongs" to the user that posted it.
This method is used in a range of different ways to structure how different types of data are related to each other. Relationships are just another field that's added to the data type. In the social media example, we could add a field to the Post data type, and that field is of type User. We can call that field whatever we want, such as Owner.
A relationship can contain one thing (i.e. a Post is connected to one owner), or a list of things (i.e. a Shopping cart contains a list of Products).
Let's again go over the earlier examples and see where it makes sense to connect data. We've marked the relationship fields in green.
Social media app (see our detailed guide here)
Users
Name (text)
Date of birth (date)
Profile pic (image)
Interests (list of Interests)
Posts
Header
Content
Owner (User)
Interests
Name
Project management app (see our detailed guide here)
Users
Name (text)
Profile pic (image)
Projects
Project name (text)
Project description (text)
Owner (User)
Tasks (list of Tasks)
Tasks
Task name (text)
Task description (text)
Deadline (date)
Owner (User)
Project (Project)
eCommerce app (see our detailed guide here)
Users
Name (text)
Address (address)
Products
Header (text)
Description (text)
Image (image)
Price (number)
Shopping cart
Owner (User)
Products (list of Products)
Don't worry about the technical side of this just yet – we'll cover that in detail in our article series about the database. Don't see this is a blueprint for setting up your app either – these are just simplified examples to get you into the right mindset:
Data types are the overarching types of data in your app, such as users, tasks, products and blog posts
Fields contain the actual data stored in these types, such as name, phone number, description and image
Data types can be connected through relationships, such as a shopping cart to an owner. These are just another field saved on the data type.
Keep in mind we are still in the planning stage. Planning out what kind of data you need your app to store will help you get a better understanding of how you can fulfil the vision that made you want to make an app in the first place.
Remember what we said in the first part of this section: most apps consist of a database at the bottom and a user interface on top of it. Now that we've covered the data, let's move on to the Design and UX of your app.
