Database structure

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

Visualizing your data

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 data types

Transitioning from SQL Databases? Here's what to know in Bubble.

In traditional databases, relationships between tables are commonly maintained through primary and foreign keys that act as unique identifiers. However, when learning Bubble, you'll notice that it's handled a bit differently.

Bubble simplifies database relations with its intuitive design. Rather than juggling keys, Bubble allows for direct linking of data types. This not only streamlines data management but also offers a more user-friendly and visual experience for those who don't have a background in database design. You can read more about this in the article section below.

Article section: How the Bubble database is different from traditional databases

If you are interested in learning more about the underlying technology that powers database, we also have a section that covers this:

Article section: Technical information about the Bubble database

As you map out your database, you can still think of Bubble as a traditional relational database and plan your data types and relationships accordingly.

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 fields

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

Relationships

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.

Last updated