Help with Many to Many Connection

What is the best way to set up a many to many connection? I have (literally!) parent and child tables. A parent can have many children and a child can have many parents. When I create a table of children I need to be able to see connected parents for each child, and when I create a table of parents I need to be able to see connected children for each parent.

I can accomplish this in Knack with a many to many connection on the child table. This doesn’t seem to work in tadabase. Am I missing something?

Thank you.

1 Like


This should work when you create the connection field inside of the Children table, you’ll be able to then see all the parents a child has and from the parents table you’ll be able to see all the children the specific parent has connection from.

Is this the way you set up your connection? Was there something specific that wasn’t working for you when you did it this way?

Please let us know and we’d be happy to assist.

Yes, I set it up that way - with the connection field inside of the children table 1 child to many parents.
When I create a child table in the page builder, I can see the parents for each child. But when I create a parent table in the page builder, I cannot see children as an option to display under Connected Fields.

Thanks for your help!

That would require showing incoming connections which is not currently possible. The only method to display both data sets is through 2 separate tables. 1 table would show data from the Children datatable, and the other table would be a Parent table with a details link. On the Parent details page, you can show a Children table connected to Parent.

Hope that makes sense. I’m gonna come back and edit this with a video.

EDIT: Here’s a video showing the setup -

EDIT #2: I had the same thing happen when I switched from Knack to Tadabase. Took a bit to get used to but the way Tadabase leverages the Details page to show data is great, in my opinion.

1 Like

Thanks @tim.young for your great reply and video. It makes sense, but I’m disappointed. My app is for a school - I need the ability to show a table of all children with a field showing their parents, as well as a table of all the parents with a field showing their children, without having to click on details for each parent in order to see their children.

@moe is this what you meant when you said “from the parents table you’ll be able to see all the children the specific parent has connection from.” ? Thanks!

I agree. For what it’s worth, showing incoming connections is something Tadabase was working on.

I’ve done a little work around using Integromat to search through child records connected to a parent record, build an HTML array of sorts, and feed that list of connected records back to a rich text field in Tadabase.

So in this example below, I have a datatable for Shows (events) and a datatable for Scheduled Employees. The scheduled employees table is a join table that connects to both users and shows, so each record contains a connection to a show and a connection to a single user that’s been assigned to said show. The shows are a parent record, the scheduled employees are a child record.

In a Show Details page, I have a form to add a new Scheduled Employee record. The form triggers Integromat and when I’m back at the main Shows table, you can see the data that’s been created via integromat in the field titled Crew List

Since this only runs after a form is submitted, it’s not perfect in practice but I was able to see those incoming connections. See the screen shots below.





I’m very new to Tadabase, so it’s possible I’m way off base here. I trust Moe or someone will correct me if I am.

But I’m not new to databases, in fact, I’m an experienced database applications developer and have built enrollment systems for universities. The problem you’re talking about is a classic problem with a classic solution. Notwithstanding Tadabase’s somewhat non-classic way of connecting records, I’m wondering if the classic approach might not help you here.


In a more conventional database, the textbook way to implement many to many relationships between, say, tables A and Z is to use a “join” table M that sits in the middle between each of the “many” entities. School enrollment databases are in fact the classic example of this type of relationship.

Here’s how it works (in the classical systems). You have tables called Students and Teachers, of course. But you don’t relate them to each other directly. Instead you create a third table called Enrollments, with these fields:

Enrollment Number (a unique but otherwise not very meaningful value)
Teacher ID
Student ID

And you connect Enrollments to Teachers on one side and Students on the other. Each of those relationships is a one-to-one relationship. So every record in the Enrollments table represents one student assigned to one teacher. If a student is enrolled in classes with more than one teacher, then he or she will be represented in the Enrollments table by more than one record.

Pros and Cons

The advantage of the join table is maximum flexibility. Only good example I can think of right now is, say the school wants to know how many girls are enrolled in all classes, or only in Ms Ortega’s classes. Assuming Students table includes a Sex field, this should be easy to find by searching in Enrollments.

A possible con (especially in the context of low-code systems like Tadabase or Airtable) is that, if you want, from the perspective of the Teacher record, so see a list of students, the platform (say, Tadabase) has to be able to reach through the Enrollments table to the Students table two hops away. But even if you use a platform that supports that, you’ll probably end up using the Enrollments table most of the time in any case, because of its flexibility.

Doing it in Tadabase: the tables and connections

I just threw this together in Tadabase. Let me say again: I’m a Tadabase novice so proceed with caution, if not downright skepticism. And I admit I see a couple little problems that I myself don’t offhand know how to solve. But here’s what I did.

I created very simple tables for Teachers and Students, with just a Name in each table.

Then I created an Enrollments table. It needs to have a display field so I called it ENum (for “Enrollment Number”). I imagine this would be a unique number but I was just entering values by hand as I created enrollment records; it’s actually not very important here. After creating that one field, I then created two connections:

  • Enrollments-to-Teachers
  • Enrollments-to-Students

Here is what the Enrollments table looks like in the Data Builder:

Here’s what the connection diagram looks like:

Doing it in Tadabase: The pages

Finally, I created a page called Enrollments. I placed on it two basic components: a table showing enrollment records by student and another table showing enrollment records by teacher. [NOTE: This is an edit to what I originally posted, which I think might have been confusing.] I’ll skip over the details, but I configured each of these components so that the items were grouped (by student name in the Students component and by teacher name in the Teachers component) and I enabled the show/hide toggle. This is what I see now:

Note that student Jenny is enrolled in classes both with Mr Johnson and Ms Ortega. Teacher Mr Johnson currently has two students, Jenny and Luis.

Couple of comments

I made a single page just to make showing it to you easy. In real life, I’d create separate pages for students and teachers, add links to the menu. But the key thing to note is that each of these pages would be based on the Enrollments table. The “raw” Students and Teachers tables would be used only for basic data entry of person’s names and a handful of other qualities (sex and DOB for students, perhaps, SSN perhaps for teachers).

I’d also add filters or whatever I needed to be able to search for particular teachers or students.

The practical use case for many-to-many relationships (as distinct from the easier example we’ve been discussing) involves not just teachers and students but CLASSES, and in the university settings, there’s often a distinct entity called COURSES. So both Mr Johnson and Ms Ortega might be linked to the course French 101, but each teaching their classes at different times. It can get complicated – but the basic approach is just an extension of what I said above.

If this just muddied the waters I hope you stopped reading five minutes ago. :slight_smile:



@WilliamPorter @camille

This is a terrific explanation of join tables. I think you did a great job elaborating on my earlier comment, so thank you for breaking it all down.

A few things I’d like to add.

  1. when displaying the join table on a page, Tadabase has a great record grouping feature that would help to consolidate the parents of a child or children of parents, depending on which field is grouped.

  2. “A possible con (especially in the context of low-code systems like Tadabase or Airtable) is that, if you want, from the perspective of the Teacher record, so see a list of students, the platform (say, Tadabase) has to be able to reach through the Enrollments table to the Students table two hops away.”

This is extremely important to consider. This problem can be solved by adding additional fields in the join table and using record rules in forms to set values based on connected values.

1 Like

@WilliamPorter @tim.young

Thank you both for your thorough replies! I appreciate it very much. I’ll experiment with the join table and see how that works for me. I’ve always found modeling families a challenge, between multiple parents and students and allowing for different households, etc. This has been very helpful. I’ll let you know how it goes.



I think mapping relationships within families is one of the biggest challenges we face today as database application developers, mainly due to social changes. When I got started doing this stuff, it was, as a practical matter, not unreasonable to define two fields right in the Children table, one for Father and one for Mother, perhaps with a third field (“Other”) to handle exceptions. Of course there always were exceptions, but they were exceptional. Now the exceptions have become the norm.

Anyway, three additional comments.

1, Join table can have other fields

I want to mention that the join table can have other fields if you would find them useful. For example, you could have a Parent Role field. So if there are two join records for the same parent (Larry), his role with respect to one child could be identified as “Father” and his role with respect to another child might be described as “Step-Father” (or “Uncle” or “Legal Guardian” or whatever).

(You could have two Role fields: Parent Role and Child Role. But I’m not sure that’s necessary. If parent role = “Step-Father” does that not logically imply that child role = “step-child”? Seems to me it does. I generally describe the parent role only.)

2, Join table might or might not be good idea

I don’t have any idea of the scope of your project. Whether a join table like I described is worth the trouble or not, is a decision I’d make (if it were my project) only after I got a good handle on how my client was going to be using the app. For example, in theory you should always put addresses in a distinct Addresses field and then connect them to the people records, because that gives you maximum flexibility. But in practice there are situations where it makes good sense to stick one or two addresses right in the Persons table and leave it at that. Understand the options and then pick the one that works best. Same thing might be true of the problem you’re dealing with, of linking children to parents.

3, It can get worse!

Finally, let me note that linking one adult to one child through the join table is easy. The headache-inducing challenge is keeping track of how the adults are connected. :slight_smile:


1 Like

@WilliamPorter Thanks for sharing your wisdom. Unfortunately my free trial ran out before I had the time to experiment with the join table. If I decide to purchase a plan, I’ll be back. Thanks again!


HI William,

I came across most of the challenges you mentioned when creating my template database designed for faith school market. When creating this standard model last year, I found it was difficult to design-in fexibility to handle all exceptions ( divorced parents etc… ). I found the paper application forms still had a role in the digital era. If students are young children (<10 ) there are safeguarding requirements to consider in the way info is received, securely stored and processed. i.e a face to face between school admin and parent(s) exist in the enrolment process for good reasons.

The paper application form is attached as a document against parent profile. Student(s) are then added to parent, ( One parent to many children ) tadabase will auto add Parent into Student table if baseline page is Parent table.

During new student record submission under form > record rules the option of add child ID into Parents Table ( user account field ) using 1 of 4 action options displayed inside record rules. This puts a list of child IDs into a field held inside Parents table ( user account table ). To achieve this though, child basic record has to be created first then at stage 2 once child ID is stored in child table - you can either assign child to one or more parent from drop down list or use record rule action to append child ID into parent table.

This creates many to many in both tables, to avoid circular reference problems the child record submission should be done in 2 stage process as described above.

Unlike MS Access/SQL ( PK_FK) days where 3rd table was required Tadabase table column is able to hold more than on child record ID inside relational Parent field column. This capability does away for need for 3rd table to manage many to many relationship.

I used the good old fashioned 3rd table method for document attachments as Tadabase at that moment in time didn’t have Many files option as it does today

For the school standard model database I kept one-to-many because i used the paper application forms ( file attached to parent record ) to managed the rest.

Screenshot of my table relationship diagram is attached below if that helps anyone to avoid months of late nights trying to build school database for children who are too young to have email account.

I was wondering if you have done the class attendance register. I have, it was difficult but got there in the end. I am happy to share it if anyone wants to see my version. Im sure its not the best but worth sharing it to learn from others in exchange.

The reset button is there to undo, I have a task running daily to reset the register. Submit button triggers another task which confirms the register and appends records to ‘attendance’ history table.