Many-to-many relations

[xam]

Hi !

I’m designing a system to track Entities (e.g., projects, locations) and Elements (e.g., equipment, tools), where the same Element can be linked to multiple Entities—but each link needs to store custom attributes (e.g., a unique image, notes, or status for each Entity-Element pair).

Current Approach

I’m using a “join object” (inspired by relational databases) to represent the relationship:

1. Entity type: Represents the main object (e.g., “Project A”).

2. Element type: Represents shared items (e.g., “Tool X”).

3. EntityElement type: Acts as a junction with:

   • A relation to Entity (LinkedEntity).

   • A relation to Element (LinkedElement).

   • Custom fields like Image, Notes, or Status for the specific pair.

Example:

• Entity A + Element E → Image1, Notes1

• Entity B + Element E → Image2, Notes2

Questions for the Community

1. Is this the recommended way to handle many-to-many relationships with custom attributes in Anytype, or is there a more native/efficient method?

2. Are there pitfalls or limitations to this approach (e.g., performance, usability) that I should anticipate?

3. How would you display these relationships on an Entity/Element page? I’m currently using relation blocks, but I’m open to better UX patterns (e.g., inline objects, sets, or templates).

4. Are there alternative setups (e.g., using sets, nested objects, or formulas) that could simplify this?

5. If Anytype adds native junction tables in the future, would this design still be compatible for migration?

Context

• I need to avoid duplicating Elements or Entities.

• The custom attributes (like images) are critical and unique to each pair.

Why I’m Asking: I want to ensure scalability and maintainability as my database grows. I’d love to hear how others have solved similar challenges or if there’s a feature I’m overlooking!

Thanks in advance for your insights

This question was drafted with the assistance of a language model to ensure clarity, as English is not my first language. All ideas and use cases are my own!

[C.c]

Yes!!! I am all in for many-to-many connections if when such function is fully implemented in Anytype. I am glad I am not alone here pushing for this. Here are a few posts that mentioned or demonstrated the importance of many-to-many relations (sorry, it is mainly me saying things )

• Multi-dimensional Relations - some discussions on matrix which should be similar to junction tables, and some small points on nesting, performance, query and more. This might be difficult to read
• Reason why is hard to understand relations and how to improve - mainly on relational data model
• Trying to actualise a use case (Bible Study) - one of my use cases which would heavily rely on sophisticated display of objects as multiple identifiers for many-to-many relations.

My current setup technically utilises one-to-many relations, but in my mind they are in fact many-to-many relations.

• I input multiple objects within a single relation, treating many as the basic unit; unless I foresee myself filtering by its different connection nature e.g. CoreRelation for parent hierarchy (also as topic/area identifier) and SideRelation for sibling, I don’t separate multiple relations. I would put all media within the same AttachmentRelation.

• I have an object type called Connection, mainly for explaining terms/concepts. Each individual object acts as a hub (one-to-included-many) storing texts that explain how included objects are related to other included objects (many-to-many). ConnectionObject will have all included objects in CoreRelation as parents (not bidirectional). This object type can show Object A + B ⇋ Object C + D.

• Generally, I like to use sets for seeing properties/relations, regardless of one-to-many or many-to-many. Queries enable filters the contents of relation, aka the included objects within a relation.

There are a few limitation to my current approach:

• Graph: The more edges (node connection line) you have, the longer time it will take to load the graph. Because we don’t have filter by relation on graph yet, the more edges you have, the more cluster the objects nodes are, because the edges pull objects together.
• I can’t keep track of all the many-to-many combinations and I don’t intend to do so because I flood my relations with objects and every object is unique by nature. Searching objects in relation before adding is my way to confirm object is unique.

FR Build title from relations and Advanced Filters / Queries should serve you well.