Understanding Bubble's unique database structure
If you are from a traditional developer background and have spent a lot if time optimising database driven apps, you may find Bubble databases counter intuitive.
When I first started developing apps on the Bubble platform, I’d come from a traditional developer background, building with relational databases. One of the things I loved doing was database architecture and optimisations.
I was quickly caught out when I realised how differently Bubble handles its database structure. Underneath the hood, Bubble databases are based upon PostgreSQL. But you may as well forget about that, as none of it matters.
It’s time to unlearn a few old habits.
Here are some of the key things where Bubble’s database structure diverges from the traditional approach, and why these differences matter.
1. The Concept of Primary Keys and Foreign Keys
In traditional databases, primary keys and foreign keys are foundational concepts. A primary key uniquely identifies a record within a table, and foreign keys are used to link records between tables. However, in Bubble, while these concepts exist behind the scenes, they are abstracted away and you need to trust that it will work well.
Bubble's Approach:
Primary Keys: In Bubble, every data entry, known as a "Thing", is assigned a unique ID. However, unlike traditional databases, you rarely interact with these IDs directly.
Foreign Keys: Instead of using foreign keys, Bubble allows you to directly reference the actual "Thing". This means you store the entire object (or a reference to it) rather than just an ID.
This abstraction simplifies the development process, allowing you to focus more on the logic and less on the database schema.
2. Minimal Use of IDs
In traditional databases, IDs are frequently used to connect tables and fetch related data. In Bubble, the paradigm shifts significantly.
Bubble's Approach:
When you need to connect different data types, you don’t save the unique ID of a Thing to another Thing. Instead, you save the entire Thing itself. For example, if you have a
UserThing and anOrderThing, you don't store theUser's ID in theOrderThing; you store the actualUserThing.
This might sound strange at first, but it streamlines data referencing and reduces the need for complex joins and queries.
Which leads us nicely onto joins.
Orzo Blue, concentrate on delivering exceptional Bubble.io solutions tailored to meet your unique needs. If you're looking for a dedicated & commercially aware partner to bring your vision to life, let’s connect and explore how we can help you succeed.
3. No Traditional Joins
What do you do if you want to reference data from two tables at the same time?
In a relational databases, you would create a join to combine rows and return rows from more than one table. Bubble handles this differently.
Bubble's Approach:
Bubble does not support traditional SQL-style joins. Instead, if you need data from multiple tables, you create a structure where a Thing references another Thing.
By using Things as references across different tables, you essentially create a virtual join. This approach reduces the number of searches and the computational load, optimising performance.
Many new Bubble developers make the mistake of performing multiple searches to get related data, say for example in a Repeating Group. Which is grossly inefficient. Understanding this key principal avoid this mistake and leads to a more efficient application.
4. Managing One to Many Relationships
Well, as we discussed in the previous point, you can’t join tables. So how to you manage one to many relationships? This is again handled differently.
Bubble's Approach:
Instead of creating a separate join or intermediate table, as you would in a traditional database, you can store a list of Things directly within another Thing. For example, a
ProjectThing can contain a list ofTaskThings.
This means you are storing an array of Things within another Thing. This not only simplifies data management but also gives you the structure for querying related data more straightforwardly.
So what does this all mean?
Bubble, as a platform, is designed to abstract away any of the key decisions a developer would traditionally make, meaning the focus can remain largely on ideas, business logic and implementation.
For developer coming from a traditional background, it does require a shift in thinking. And for those of us most interested in ideas, rather than process, it give us and our clients the opportunity to test the market and measure demand.