Creating two Things - child/parent relationships

Hi Bubblers,

I’m wondering what the best solution/workflow is to accomplish the following action. I have 2 Things in my database that are created on Sign Up button click, both a User and a Company. I need to add those two Things into child/parent fields and not sure if what I am doing now is most efficient.

  1. User
    field: parent_company (Company)
2)  Company
             field:  team (*list of Users*)

How I have the workflow set up now is when my “Sign Up” button is clicked:

Step 1: create User

Step 2: create Company
- add User from Step 1 to “team” field

Step 3: make changes to User
- add Company from Step 2 to “parent_company” field

Just curious if there is a better way to work this using custom events or using a completely different database structure that will allow for each Thing to reference the other in searches. It seems like having a “Search for Company team” team containing Users associated to that Company would be faster than "Do a Search for Users who’s parent_company = Company. After reading a few threads, it seems having to change data in two places could be problematical the way I have it set up and should be avoided.

Really appreciate any insight!

1 Like

Regarding having a field for Company which is a list of Users, I think it depends on how many users will be assigned to that company. Bubble documentation says that shorter lists in list fields are OK, but longer lists can slow performance (I think Bubble says keep it under 100, but check the documentation). I think the reason for that is because a long list embedded in a thing makes the thing data-heavy, which bogs things down, as discussed here: Alternative approach to the Bubble’s recent tutorials for list of things

I personally would only link it one way – having the User have a Company field. That allows maximum scalability and keeps the database efficient. Bubble should be pretty fast pulling a list of Users for a Company, since that search is done server side.

That said, with Bubble, the “right” database structure largely depends on how you are planning to search and show the data. There could be scenarios that would call for you to do the links both ways. For example, if the list of users for a company were minimal, and you wanted to show RGs of lots of companies and lists of users displayed next to each company, then #1 may be faster.

1 Like

Yup. Also, if the User has the Company field, you can easily configure the privacy stuff.

Company Table:

  • name | text
  • description | text

Invoice Table:

  • Company | Company
  • amount | number
  • User | User

User Table:

  • full_name | text
  • Company | Compay

Current User’s Company is This Invoice’s Company
enable fields

Really appreciate the info @ed727 I will stick to just using a User with Company field.