The first term from the book is the Data Concept. What you’ll find about these expressions is that they serve as a model of thinking – a way to reset the frame on how we think about our Bubble database.
The idea about the Data Concept and the reason for why we think it’s needed when we discuss database performance, is that we need to unchain ourselves from the thinking that the Data Type should somehow reflect perfectly our client’s request or how our Users see our app. Let me explain.
Whenever you have an idea for an app or a project plan you’ve worked out with a client, you will have a list of different things that you need to store in your database. In the book we use the example of a CRM built for a client, and assume a database containing data on:
- Clients
- Vendors
- Contacts
- Projects
On the surface, these look like four different Data Types in Bubble, and in many cases the first thing that Bubblers do is to enter them all into their database. We call this using Bubble as your notepad, and it happens more frequently than you might think: setting things up is so quick that it’s easy to simple add everything as a first step simply to remember it.
But what if we pause for a minute here and have a quick look at what we’re setting up.
What is a Data Concept?
It can be somewhat confusing at first why we need this term, when Bubble has already introduced us to the perfectly good Data Type. The difference between the two is:
The Data Type is what you’re actually saving in the database. It has a name and whichever fields you give it, and it typically doesn’t change once you’ve set it up.
The Data Concept is how the User/Client sees your data. It reflects the User Experience of your app, but doesn’t necessarily reflect the actual setup of your database.
The reason we separate these two models, is that it’s not always beneficial that the two match. Remember, your job as a developer is not to do exactly what your Users or Clients tell you, but to create an app that solves their problem in the best way possible. Sometimes, that means setting up your database in a different way than your Client would suggest.
We’ll illustrate this with a quick example, and expand upon it as you check out the rest of the terms from the book.
Clients and Vendors – how are they different?
Part of the database structuring process that we lay out in the book is to get to know the Data Concepts we’re working on in detail before setting anything up in Bubble. Now, let’s have a look at the two top Data Concepts: clients and vendors.
Let’s first have a look at the Client, and what kind of fields we would typically need:
- Name
- Phone
- Address
- etc
Now, let’s look at the Vendor:
- Name
- Phone
- Address
- etc
Now, thinking further about the requirements we would need for these two Concepts, we’d stumble upon the same thing. They both need to be:
- Quickly searchable
- Viewable
- Editable
- Hidden by Privacy Rules
*Gasp*! Are you seeing what I’m seeing? They’re basically the same thing! Thinking further along those lines, isn’t it possible that a Vendor could also be a Client at some point?
Separate Data Concepts, but same Data Type
As we can see here, there’s good reason to simply combine Client and Vendor into a single Data Type. To separate the two, we can use an Option Set (Company Type with the Options Client and Vendor) or whatever you want to call it) to separate them, and to use a List of these Option Sets if we want the ability for a Vendor to also be a Client.
Had we thought of our client’s data requirements as Data Types, we might have missed this opportunity to set up our database more efficiently. Because we used the Data Concept model and unchained that from the database, we realized that the way a client or idea describes a certain type of data doesn’t have to perfectly illustrate what your database actually looks like.
Other uses of the Database Structuring Process
The term Data Concept and the other expressions listed in this guide are all part of our Bubble Database Structuring Process available in the book. In that process, we take each Data Concept through three steps to ensure it’s set up in a way that serves the app best.
The example above is a typical case for separating Concept and Type, but by no means the only one. In this example, we merged two Data Concepts into one Data Type, but there are other scenarios where you’ll want to add an additional Data Type rather than merging.
This is described in the concept of Satellite Data Types, which we use to solve specific challenges, often related to search performance and Data Weight in different scenarios.
This article gives a quick introduction to the Data Concept and how it’s used, but for the full Data Structuring Process, check out The Ultimate Guide to Bubble Performance.
