We noticed internally that as we grow our Fibery database and consolidate various relationships, we have quite a bit of self-relationships in our databases. Think for example “Depending on / Dependant” relationships. Those relationships currently are very hard to represent and properly address.
The wish would be to be able to represent these relationships in a view. This could be represented with a symmetric N x N matrix (where N is the amount of entities to be shown), with each relationship of the database shown as a a letter, with optional colouring on conditions, for example. This would also make creating these interdependencies extremely fast and efficient, without having to check each object individually.
Below is a very simple and silly example of a database “Steps to eat pasta”, where we’re mapping the relationship “depends on” with “X”. We can read it by, for example, looking at the second row of the first line; B depends on A. This representation could be used for any “intra-database” relationship and could even map several at once.
In the case of “Depending on / Dependant”, we basically end up having a Design Structure Matrix, which I think could help a lot of users wrangle complex dependencies and could put Fibery even more on the map for complex systems engineering tasks.
Hey! If this is really important, there is a solution you could go with if you added a junction database. It can even be populated and unpopulated automatically based on linked and unlinked relations.
This would be a database with two to-one relations to the same database, “Depending on” and “Dependant” relation. Then you can make a board view with columns and rows to make this matrix.
Then you’d add the following automations and formulas:
(On the task db) On link, create a new junction entity.
(On the junction db) A “Delete?” formula that checks the “Depending on” entity, and checks if it contains the “Dependant” entity in it’s relationship.
(On the junction db) Rule that triggers when “Delete?” is updated and equals true. Action to delete the entity.
It’s a bit complex, but it should work!! If you need a hand with it feel free to reach out!
Hey! This is very good input, I hadn’t thought of that. It does yield a proper table, but it doesn’t exactly make it easy to work with, nor very readable (as a board has a lot of margins everywhere, since it’s not really made for that use). My example of eating pasta with only 5 lines basically takes a full screen already.
For the time being and my use, I might try this on live data and see.
Nevertheless I think the feature would still be nice and would give a very powerful visualization tool to any organization that has internal relationships in databases and wants some insight into them, be it dependencies, related-ness, duplicate-ness, or anything else really.
I’ll agree that it’s not necessarily the kind of view that one instinctively wants to have / thinks they need, but I’m pretty confident having it as a ready option and trying it out to see the result would definitely add a lot of value to some organizations (I mean, DSM is a thing for a reason after all).
Yeah, I’m just thinking of maybe a way to make it more flexible and not just a single use case. How it could be set up in a way that it can also help with other situations.
