Forum Academy Marketplace Showcase Pricing Features

I need a better understanding of how the DB works

I develop websites using PHP and MySQL and am trying to learn bubble to possibly speed up my development time on smaller apps.

I’m sure the problem is that I’m coming from a SQL DB standpoint and bubble’s DB is much… looser?

I’m struggling to learn how the database system works… I’m guessing data type is a table, and fields are, well fields, but exactly how does “This field is a list” apply?

Does anyone have any free tutorials on the DB side of things?

Since I have experience in MySQL would it be better if I built it out in that and used the SQL DB plugin?

I’m also wondering about this. How is indexs arrangere? Since Bubble now use postgres some gains could be acheived if users could specify secondary index and index based on muliple keys. However this should be limited to users who knows database.

Yes, a Data Type is a Table. A Field is a Field. A Thing is a Row/Tuple/Object.

Worth mentioning “Field Type” and how that can implement Relationships. So beyond “text” and “number” a field type can take the type of an existing Data Type. So instead of a foreign key, we are setting the field to be a reference to another Thing. We could have Vehicle, which could have a field Manufacturer, or type Manufacturer … where there is another Data Type called Manufacturer. And we Set that field (on Vehicle) to be a particular row on the Manufacturer table.

This becomes powerful in Bubble because it enables the natural language data access. So for example, if Manufacturer had “Name of Sales Contact” … and we are displaying a list of Vehicles, we can navigate the relationship simply by using an apostrophe. So we can use Vehicle’s Manufacturer’s SalePerson’s Email Address for example. In SQL that would need a query, and you would need to know the foreign keys.

Lists are basically Bubble’s way of implementing “One To Many” relationships.

So you can have a list of texts. And as you go along your can add/remove texts from that list.

Where they really come into their own is when you have a list which has a field type which is another Data Type.

So … if you have a field on User called “Friend” which is type User and also a list, then you can use the same language as above. A repeating group that lists out Current User’s Friends.


This has helped considerably, thank you!

I still need further DB help if anyone is willing to provide it. I’m afraid it may be out of scope of a forum conversation, and I’d be willing to go to some sort of chat platform if necessary. In the meantime… here goes…

I’m working on a contacts app that allows a user to sign up their organization and add sub groups and the individuals that belong to those groups. The individuals would be able to sign up and edit their information and the sub group’s information that they belong to. Additionally, the user that signs up should only see the organization/sub group’s information that they belong to. Also, any information changes would need to be approved by an admin of the organization.

I had the db mapped out in mysql as well as some of the logic detailed out in php, however I’d really like to use Bubble if possible.

I’m falling short of defining a check that will only output information (org, group, individuals) where the logged in user’s email address matches one of the individuals… I’ve got a feeling that Bubble’s conditionals just aren’t complex enough. I don’t want to merely hide the element behind a css display:none. I want to prevent it from being loaded at all.

I think that’s definitely possible. You could set that situation up by setting up the data and pages in this way:

Data Types (in bold), Fields in Quotes:
Fields within Organization:
“Creator” (Built-In)
“Subgroups” (Type: Subgroup, List: Yes) <— List of the Organizaiton’s Subgroups
“Users” (Type: Users, List: Yes) <—List of Members of the Organization

Fields within Subgroup:
“Creator” (Built-In) <–User who created the Subgroup
“Parent Organization” (Type: Organization, List: No) <—Organization this Subgroup is a part of
“Users” (Type: Users, List: Yes) <----List of Members of the Subgroup

Fields to create within User:
“Associated Organization(s)” (Type: Organization, List: Yes, if they could be part of more than one Organization)
“Subgroups” (Type: Subgroup, List: Yes) <—List of Subgroups the User is a part of

So, if you had a User navigate to their own profile page (Type of Content: User), where they could view/edit information about the subgroups they are a member of, you could have a repeating group (Type of Data: Subgroup, Data Source: Current User’s Subgroups). Then the repeating group is only going to display the Subgroups retrieved from that User’s List of Subgroups. From there, you can provide the User with the ability to submit changes to be approved by an admin.


Are you looking for it to work in the same way that things like Basecamp work, in that you get permissions automatically based upon the email domain when you sign up, rather than someone having to sign you up ?

You can extract the domain from an email address using :extract/email/domain…

You would need to make sure you forced email verification on sign up, but you could do it (similar to the above) by setting up permissions on the domain globally.

1 Like