# Representing nested relations

**URL:** <https://community.fibery.io/t/representing-nested-relations/1405>\
**Category:** Ideas & Features\
**Created:** [February 25, 2021, 7:34pm UTC](https://community.fibery.io/t/representing-nested-relations/1405 "2021-02-25T19:34:31Z")\
**Posts on this page:** 1\
**Showing post:** 20

<div class="post-metadata">

**Author:** ![Chr1sG](https://sea2.discourse-cdn.com/flex020/user_avatar/community.fibery.io/chr1sg/32/3941_2.png) [@Chr1sG](https://community.fibery.io/u/Chr1sG)\
**Post date:** [December 12, 2021, 11:05am UTC](https://community.fibery.io/t/representing-nested-relations/1405/20 "2021-12-12T11:05:52Z")

</div>

> [@cannibalflea](#):
>
> neither app have any databases that have relations to themselves

Sorry, I guess I wasn’t clear 😕  
When I presented the two examples, I was just trying to imagine that a user could have developed a space with similar complexity **and** included self-relation for one or more of the lower levels.

In your example, you wrote:

> [@cannibalflea](#):
>
> for every Project that is at the root of tree (i.e. has no parent Project), you will see if a Program relation is specified. If yes, then we insert/nest the Project (and any associated sub-Projects) inside that Program.  
> If not, you will see if a Portfolio is defined and nest the Project there.  
> If all fails, then the Project would be added to the “No Portfolio” list

This is based on an implicit assumption that Program-as-parent relation takes priority over Portfolio-as-parent relation. When looking at the hierarchy diagram, that is a reasonable deduction.

However, taking the Usability Testing as an example (and assuming that Attempt is self-related) I am struggling to see how your logic could work reliably.

Based on your ‘rules’:

1. Build each database’s nested structure ✔
2. Try to map root items ❓

If a hierarchical list is to display all databases, I can’t see how Fibery can determine whether an Attempt should be prioritised to be mapped under a Participant or a Task?

I guess the answer is that the user is required to choose a single ‘hierarchical path’ (either Test → Participant → Attempt or Test → Task → Attempt) and that resolves it. Maybe that’s OK.  
But this is a constraint that is acceptable/valid for one-to-many relations.

I am aware though that any changes made to support self-relations need to be compatible with (future) support of many-to-many relations:

> [@\[DONE\] Many-to-many relationships should be usable for levels in lists](https://community.fibery.io/t/many-to-many-relationships-should-be-usable-for-levels-in-lists/1624):
>
> I have [Product] \*------\* [Feature]. (Features belong to products, but some features span multiple products; e.g. “2FA” is a feature of both the backend CMS and of the mobile app). There is also a [Product] ----\* [Bug]. (A product can have bugs.) When I create a list, I can add Bug as a second level, but not Feature. Why not?

Implementing specific logic for self-relations might hinder that future development.

To be honest, I totally want to see self-relations at lower levels, so I hope the dev team can figure it out without painting themselves into a corner.

---

_[View the full topic](https://community.fibery.io/t/representing-nested-relations/1405)._