Ok @rhywden , the feedback I get from you is that I need to write in the docs a “SQL relationship comparison” because any type of relationship is achievable. But people are very familiar with those and they need a point of reference
So let me explain we have 4 types of relationships “One”, “One-Meta”, “Many”, “Many-Meta”, the name refers to how the data is stored: How many links we store. The overall relationship status is defined by you. However we support One-To-Many by having the storage in the “Many” side like in the SQL. You can also have One-To-One which is a “One” relationship with “unique: true”.
@gothicmage there is a way !
A Many-to-Many relationship can be a simple “many” relationship example:
This can also act as One-To-Many indeed, if all your groupIds from all users are unique. But if it’s truly One-to-Many keep the storage in the “Many” side.
That’s it. Here’s your Many-To-Many relationship
Performance is not an issue with Grapher. The queries are very fast. Because of the aggregation of filters and re-assembly. I’m not sure if it’s faster than SQL joins, someone can test this
Plus if you have a M2M and expect having a lot of fields 1000+. It is not a problem. Grapher forces you to take only the fields you need. And if you want the linked elements, you would have taken those 1000 either way.
Now coming back on “SQL reationships”. MongoDB is something new, the relationships in SQL can be easily modeled in MongoDB with Grapher, but the way we think about relationships needs to change, this is why in the API of Grapher there is no such thing as “One-To-One” … Because there is so much more to it. For example, instead of having separate tables for Many-To-Many, you store it directly as array. If you want to put additional data about your relationship (like User has many Groups but he is admin to some), you specify metadata. This is superior to SQL in my opinion, and far easier. It was tricky for me at first to shift from SQL relationships.