I know there can be many more details needed, but in general:
Is it better to relate smaller elements (ex. taks) to a bigger parent - ex. big project - by saving big project on smaller element? - this way once I do a search for smaller elements I can display this in one group.
Is it better to relate smaller elements to bigger parents - so that I cannot do a search for tasks but I can easily display projects tasks.
I currently work more often into adding details to smaller elements - so that ex. task has a project, project lead etc.
I usually do it as it makes much simpler to create them - so I just make create element where project = X, etc.
Other case I would need to first create them them align them to parent in another step.
But sometimes I m missing the function of doing on a project site a simple - all projects tasks.
Thou - I do not want ever to save on both as it can lead to problems and omissions. So saving on both isn’t an option.
But is there a general rule of how should I approach that case?
Is there a logic to which approach I should more lean to?
A Tasks list field on a Project can get messy fast if you don’t maintain it, or if multiple people are modifying the list at the same time, and you would be always filtering it instead of using search constraints.
While with traditional databases i would not recommend using bi-directional relations, with Bubble I dont think it can be considered bad practice.
Bubble does not offer the ‘join’ functionality. Without it, handling relationships becomes quite a lot more annoying, proper database normalisation is not really possible in most cases, and the industry recommendation of never duplicating data on different tables does not hold as much.
I think bidirectional relationships have their place in Bubble for now. Hopefully an operator similar to a join will come at some point but i do not see it happening soon. I think you should at least consider linking both tables to eachother, in some cases it does work well.
You can use Trigger Events to make sure that relational fields stays consistent between the two tables.
As @tylerboodman mentioned, lists can become problematic if multiple users can edit them concurrently, OR if you expect that the list could become larger than 500 elements (debatable number).
Lists can be great for use-cases where the above problems do not apply, as they are faster than searches, and much more easily sortable. Sortable searches are a pain.
This could be helpful:
Exactly without the join operator you cannot effectively filter without having some sort of redundant fields. I sometimes duplicate the filterable parent fields onto the child elements. Someother times I use bidirectional relationships instead and reference the Parent’s list of children. In the end it depends on the particular use case
without the join operator you cannot effectively filter without having some sort of redundant fields. I sometimes duplicate the filterable parent fields onto the child elements. Someother times I use bidirectional relationships instead and reference the Parent’s list of children. In the end it depends on the particular use case