I’m working on structuring my app’s data and could use some guidance. I have a bunch of bi-directional references on my datatypes and am wondering if I should pivot to a different structure.
As an example I have two core data types: User and Project. Right now:
Each User has a list of Projects.
Each Project also has a reference to a User.
This setup has made it easier to surface related data from both sides, but it’s starting to feel harder to maintain. I’m wondering if this approach could cause long-term issues. I started with this approach because I thought it would save me WU by eliminating the need for a bunch of search and search within search functions.
My two questions:
Is it bad practice to have both data types reference each other?
What guiding principles do you use when deciding how to structure relationships between data types?
So normally, yes, this is not the best idea. Have a list of projects on the user weighs down the user dataType and makes it not scalable. It is better to have a project with the reference to the user and have the privacy rules set up properly.
Someone else might have a different opinion but I think, from what I have seen on the forum, the long term bubblers and developers usually build this way.
The answer is always going to be “it depends”. Your hunch is correct (maintenance overhead for both datatypes), although, there’s some valid reasons why you may need to do this, and it all comes down to 1 thing: Design!
Your UI/UX will drive what you need to do in Bubble, noting that there are a lot of quirks and non-standard things you may need to do e.g. a “search” data type for complex filtering and sorting. Privacy will also be a consideration for how you structure your DB.
If you sketch out your screens, even with pen and paper, it should give you and idea, and will place people in the forum in a better position to provide good advice.
It’s definitely not bad practices to double link… if it’s needed. Adding a field to a dataset makes almost no impact. Unless it’s something that’s changing all the time, maintenance is also negligible. (use a DB trigger if you want.)
I always OVERlink to start if I’m not sure that I need a double link (or which single link will end up making the most sense), as it’s super easy to remove a link.
That being said, in your case, where the potential double link is a list, @J805 is right that it shouldn’t be on the user itself but on some satellite dataset instead. Also, if a user can have lots of projects, that may be a reason to not double link. Although even then, you can split the difference and have a list of active projects in the user satellite dataset. This will avoid doing a search for active projects, which would be the most common projects the user would be pulling up (i.e., downloading to the browser). Then you can note the existence of inactive projects or keep a count of them so you can show the user and only search for such projects when the user expresses the need to do so. This also can easily be maintained with a DB trigger (e.g., when a project is changed to inactive, remove it from the user’s active projects list and increment the inactive projects count by 1).
i do this all the time to reduce searches. You absolutely have to maintain this yourself so add/delete via custom events (or database triggers) so you only have to make modifications in a single place.
I make bidirectional links when I find myself needing to find Thing B by thing A, but also often need to find Thing A by B.
So in my current project, I have users on the project, but dont have projects on the users. I only need to find the projects for a user in a single dropdown.
Long term Ill make a roles table that relates the two.
it creates a lot of issues in development all to save a minimal WUs on the front end. if WUs become an issue you can always optimize things later on - but even then storing a list of things on a data is usually not a big needle mover
sometimes I do it though - for example I have a list of process steps and I show that in the tabs on a page when a thing is open. each step has a status and the status has a color to color the tab. these colors also show in a repeating group on the main card… so I store it on the main data to save all the searches since the search happens so frequently
