In Xano, a relationship between database tables is created using the Field type
Relationship data display A table reference is typically just an integer referencing the unique ID number from the table of the referenced record. However, oftentimes it's helpful to visualize what the reference represents beyond just the ID. With Xano, you can see the fields of your referenced record that are important to your use case.
Auto-complete relationships When entering a reference record, Xano presents you with a drop-down menu. The menu provides you with the recently added records from the table you are referencing. Additionally, there is a search bar where you can search for the id number or any of the displayed field values. You can quickly navigate using the keyboard arrows and enter key.
Choosing which data to display By default, Xano will automatically display the first text field and the id field of the referenced table record. However, you can easily customize which data you'd like to be displayed in your table reference.
In the parent table (or the table being referenced), click the menu icon in the top right (three dots), then select Auto-Complete. In this example, the parent table or table being referenced would be the merchant table.
After selecting Auto-Complete, the settings will open up. Click customize in order to customize the display of the referenced data.
You can add multiple columns, reorder the columns displayed, and remove columns from the display.
There are a few ways to handle Many-to-Many Database relationships within Xano.
An example of a many-to many relationship is one between students and classes. A student can register for many classes, and a class can include many students.
The traditional SQL to set this up has been to use a JOIN or pivot table which you can absolutely still do in Xano:
However, Xano allows you to do it another way Xano uses PostgreSQL and is a hybrid SQL/NoSQL you can simply create an object in the student table called enrollments that allows you to not only achieve the same thing but have data locality (being able to see everything in one place).
Here's a demonstration of how you would add an enrollments object (list) directly inside the student table:
There is no hard and fast rule on this, but we like to say if you anticipate your object list growing over 100, it's probably time to start thinking about separating it into a new table. You can still keep everything in an object, but it becomes a little unwieldy to manage especially because when you update objects, you're updating the whole thing (so potentially 100+ records) and if you make a mistake on how you update the data on the front-end, it could lead to some trouble.