It’s 2024 (almost 2025) and we still don’t have a native way to create Many-to-Many (aka “two ways relations” or “multiple to multiple relation”). We have hacks, we have third-party tools but that’s an ESSENTIAL feature. When can we see many-to-many relations live natively in Glide?
Explain what you are trying to do. In my opinion, many-to-many has always been a possibility in Glide, but it would help to better understand your situation better.
2 Likes
For example, I have books that can have multiple authors (a simple 1-to-many relationship), and authors who may have written multiple books (another 1-to-many relationship). Now, I want to bring everything together as a many-to-many relationship (m:n).
Following the “standard” relational model, I should create a relation table with IDs from both the books and the authors. This works well in the table editor, but it doesn’t translate smoothly to the user interface (UI). There’s no simple way for a user to select an author from a dropdown in the book editing screen or select a book from the author editing screen since these records are in separate tables. It’s also not intuitive to visualize which books belong to which authors, and vice versa. You can better understand this issue by watching this YouTube video.
Method 2 involves using comma-separated values with a relation, then splitting the text column in the books table to assign multiple authors. In the authors’ table, I would then use a relation to assign multiple books. This method works well in the UI, but it has limitations. For instance, I can’t add a new book directly from the author editing screen (more details can be found here). The workaround would be to do the same for authors as I did for books, but this approach would lead to inconsistency in the data.
Why can’t I easily connect data between authors and books, like I can with Airtable? Am I missing something?
P.S. Before using Glide’s native features, I was using Airtable with Glide. However, the latency and recent updates that disrupted my setup pushed me to try doing everything natively, resulting in the issues mentioned above.
I almost never create an intermediate table. Never been a fan of that method. But I do see the problem you are presenting when you want to approach it from both ends and allow books to be added to authors as well as allowing authors to be added to book. It does add a little bit more complexity. In my opinion, the ideal setup would be to store an array of author IDs within the book row. I think with the appropriate setup it would be easy to only store authors within books and still be able to update that list of authors while editing either an author or the book.
I guess I would first be interested to see your ideal app flow showing on the front end how you would like to be able to add authors to books and books to authors. Ultimately I recommend a comma delimited list of authors within the book row.
I’d imagine some single relations would be involved to provide editing access to rows in other tables. Just need more info on your flow.
2 Likes
I just want a simple native many-to-many relationship man. I don’t think that I’m asking some crazy new feature. Just to add something that has been around since the invention of databases…
If you have any useful suggestions, please share them here so that anyone facing the same issue can benefit from them.
Just trying to help. I don’t think it’s that crazy hard to set up currently. I’m just asking for examples of how you want it to work and what you have now so I can make the appropriate suggestions that apply to you instead of throwing out random ideas that may or may not apply to your situation. There are tons of ways to do these things, but I don’t know your app. I don’t know what it looks like. I don’t know your flow for adding authors to books books and books to authors. I don’t want to waste my time taking a stab in the dark without having all the information in front of me.
I know how I would do it if I was creating an app for myself, but I don’t want to give you a solution that causes you to rip your entire project apart. That’s why I ask for more information. It helps me provide the best solution for you.
From the book side, maybe it’s just a simple multi select choice component to select authors.
From the author side it’s a few more steps. Maybe it’s a simple search to get a book id, create a single relation/lookup to get the current list of authors for the book, a template to add the new authors, and a set column action to update the list of authors if the book. Or maybe it’s something simpler by incorporating a custom collection connected to the book that’s been search under the author. Or maybe you can write directly to a relation. Something that’s possible, but I haven’t fully wrapped my head around it.
I don’t know. There’s too many open ended questions. Not knowing anything about your app makes it hard to say what’s best.
Jeff, the fact that I have to explain my entire app and logic to you just so you can help me set up a many-to-many relationship is exactly why we need this “”“feature”“”.
I’ve seen your name on similar questions going back to 2019. Don’t you think it’s time for the Glide team to implement many-to-many relations?
When using any other kind of database or table system, I don’t have to explain my entire app to someone for them to understand how to create many-to-many relationships. So why, when people have been asking this question (since 2019), do they still have to explain their whole setup with screenshots and videos to convey such a simple concept, one that has been around since at least the 1970s? It just doesn’t make sense to me
Sorry, I was just trying to get the information I needed to try to help you effectively.
This is my take on the whole many-to-many concept based on your example of books and authors. I have no idea if it remotely matches your current or preferred app flow, since you weren’t willing to share that info, but maybe it’s somewhat close. This is purely from my imagination with nothing to go off of. It’s not a completely native solution in the sense that there is a handful of computed columns and actions involved, but it’s still many-to-many and completely built with native Glide functionality. Some of it could have been simplified further, but I wanted to maintain a consistent look, feel, and flow. There are only two tables in this project (Books & Authors). Books can be added to authors and authors can be added to books. The only thing that is editable is the list of Author ID’s within a particular Book row. That list of authors in the book row is used to establish relations from authors to books and from books to authors. Is it exactly what you are looking for…probably not, but like I said before, it’s still attainable.
I just want to add that I’m not opposed to most feature requests. I just know they can take a long time to come to fruition…if they even do. If I can solve a problem today, I’m going to make a best effort to make that happen with the tools in front of me today. To me, it’s better than sitting by idly, waiting for something that may or may not happen. If the request happens, then by all means update your app, but I see no reason to sit on something for months or more if you don’t need to and if it’s holding up your project. This ultimately took me less than an hour to set up, and most of that time was spent experimenting with different screen layouts and app flows to hopefully resemble what you might have.
10 Likes
Hi Jeff, could you put the application as a template, so I can copy it? It would be great to see how you structure your database and learn something new.
1 Like
Hi Jeff 
Does this mean that when you have a data schema in mind, the easy part for you is setting up the data schema and the harder part is expressing the data schema in the frontend?
Another possibly related or unrelated question, I’m not sure: are data schemas tool agnostic? In general, in the context of Glide? Meaning do you adapt your data schema (table architecture and attributes) to Glide because of how Glide works? Or do you define your data schema based on the features you need, and then whether it’s in Glide Tables or traditional coding the tables and variables are the same (either exactly or similar)?
I’m assuming this question is in relation to your other thread. My process is pretty organic. For me, I start with a simple data structure just to get started. From there the data dictates the front end, which further dictates the data, and so on and so forth. I usually work with both the front end and back end equally. I like to dive into a project and let my testing and the UX determine how the app ultimately looks and functions. What initially makes sense on paper may not always be the best experience in practice. It’s not uncommon for me to start with an idea and a design, and end up modifying or completely reworking the database or the front end. It should be noted though that I only build apps for myself, so I have complete freedom over my projects, and I’m not bound by pre-agreed specs like one would if they were building for a client. Having that freedom allows me to continually improve my projects and have first hand knowledge of what works or doesn’t work well.
For example, with this app, I had a pretty good idea how I would set up the tables and how the app would generally function before I even started. What took more time was deciding if I should use an edit form or a custom form. The method for setting authors while viewing a book is a lot easier than the method for adding an author to a book from the author screen (because authors are stored within books). Ultimately I wanted the user experience of adding and removing authors to be somewhat similar from both ends, so I spent a little more time experimenting with different screen designs which led to some adding and removing of some extra columns as I tried different things. Ultimately I used a New Screen action and some custom actions to essentially create a custom form to add or remove authors. The buttons on each form ultimately commit the changes to the authors column in the book table.
In some respects, yes I believe the way Glide works can have a small affect on data schemas. Limitations, such as row limits, usage limits, ability to add/update multiple rows at once, or limited access to certain column values (ie Big Tables) may lead to database structures that are not ideally normalized. In reality though, I think structuring data in Glide is going to be very similar to other databases. Good database design is pretty standard everywhere. I don’t think you will see many differences. Where Glide and other no-code tools are unique, is the fact that you have have computations and code running directly inside the table. That’s pretty powerful in and of itself.
3 Likes
I’m having to rebuild apps from scratch regularly because I feel I cannot move forward with the way things are set up. I think, but I’m not sure, some of the best builders in Glide spend so much time in the data structure and getting that part right, because if it’s not it’ll block things later. That’s probably the case in traditional and no code development. I find it very tricky to find the right data structure that guarantees that the app is as evolutive as possible, which is very important.
What I find frustrating in Glide and where I still struggle is the importance of context. On the one hand it feels logical: when in the layout editor, one “needs” to be somewhere. And by that I mean the screen is accessing data, and that data is either one item of data (a row) or multiple items of data that are logically connected (a collection). So this makes sense, somewhat. But sometimes I think why, why do I need to potentially rebuild an entire screen and potentially adapt columns because I’m adding an author to a book not from the book context but from the author context. It’s almost like the context, which in a way is also UX, might dictate data structures. It feels like you should be able to do both regardless of data structure because your data schema hasn’t changed. I’m not sure I understand this correctly. I wouldn’t be surprised if in traditional coding, tabs (top level screens) are mostly independent of context.
Anywho. Step by step. One day I might have an aha moment and everything will just snap into place.
3 Likes
As for the original topic of this thread, many-to-many relations. I’ve created these in join tables in the following app.
This week I’m building a mini-LMS application for a company that provides corporate training. The app goes something like this. The user of the application are employees who once they are part of a class can be seen as attendees (or students). A class is specific training topic (eg. Management, Sales, etc.) given to employees of a given client (eg. Google, General Motors, etc.) in a given year (the starting date is what counts) to a specific group of employees (my client might provide classes to Google on management to 5 groups of employees, the groups of employees are different but the company and training topic are the same, the year is not relevant here). Training topics contain modules which represent a date when an in-person session will be held and the modules also represent content that is going to be taught in-person. The modules contain business practices cards which basically are support cards for what was taught during the day. The cards become clickable at 4.30 pm on the day of the module or manually if the instructor decides to unblock the cards that way. So an employee will enter the application and can only access their training, and thereby their modules and cards. There’s also an admin section in the application to manage of all this stuff: classes, trainings, modules, attendees, etc. Later on there might further roles to differentiate an student attendee, an instructor and the admin (basically my client and his team). That’s the gist of it. “Easy” enough really.
Still, hurdles I’ve encountered:
- The notion that trainings contain modules, modules contains cards, the same training might have different modules (dates for sure, order and name possibly) from one company to another, same goes for cards. The things in things in things and the 1-to-many and many-to-many relations and the fact the relations might need attributes (sorting) is challenging. Thus the join tables we were talking about and @Nicholas_Sollazzo was complaining about.
- When the admin creates a new group of employees for a given training and client, he wants to just duplicate the class and that’s it, understandably. And at the same time he wants to be able to change a few things in this new classes, like perhaps changing the order of modules and cards, perhaps adding cards or modules. And either way new dates are needed.
- And the list goes on and on.
Originally I built the app without the join tables for the many-to-many relations. I’m not a huge fan of join tables either. But with the normal relations, I was having trouble seeing how data flows from one table to the other. I look at the tables now and I see relations and lookups all over the place, it’s impossible to maintain (for me).
It all sounds easy enough, but really all these details and intricacies are challenging, to me at least. And these edge cases keep popping up and I’m thinking “Doh, how the hell was I supposed to think of that”.
Anyway, I’m not at all asking for input, not at all. I’m just rambling for the sake of rambling but also to share that it’s not all that easy. And nobody said it was 
And yeah, go joined tables for many-to-many relations so the admin can change the order of those modules and cards.
2 Likes
Enjoyed this thread and it discusses exactly what I’ve asked in a different thread. I’m sure that I’m missing something obvious.
The many-to-many concept above is exactly what I’m looking to achieve through a joining table.
Thanks
1 Like
It’s time to have this “feature”. Please upvote the thread so we can let the devs know that we need it
1 Like