I am referring to the advanced option for linked relation columns
Can someone point me to documentation that explains this in detail, or explain it here. I just have not been very clear on what this means exactly.
Is the only difference that a linked relation offer 2 way editing? its not clear to me when why there are 2 options for this because the functionality is so similar. what am i missing?
Perhaps this is a legacy feature? relation columns came first so those are preserved like they always were but for something new it makes more sense to go with linked relation…?
what are the use cases for a relation column when linked relation exists?
this section of the documentation quoted below covers my question exactly, but i still don’t get the 2 different uses cases 100%. if anyone has examples of how they use it, that would be appreciated
A relation column represents the primary connection from Table A to Table B, whereas a linked relation represents the other side of the connection on Table B - and even lets you edit values back in Table A.
Another way to think of it: one relation column can have many linked relation columns connected to it, while a linked relation column is only connected to one relation column.
the part you highlighted in your original question seems to go one step further–switching which column is the “relation” and which is the “linked relation.” I’ve never really understood that one! how does one decide which should be side A and which should be side B? and if they are really two-way, why does it matter?
In most enterprise-scale relational database systems, we only ever use a link from one table to another that has a single value.
So..
If your customers have many orders then there is no link from the CUSTOMERS table to the ORDERS table, but there is a single link from each ORDERS row to the CUSTOMERS table row for the customer that owns that order (lets call that column Customer).
In Coda, this is the primary relationship: I go to the ORDERS table and add a relationship column that links to the CUSTOMERS table.
In that scenario, when I want to find all the orders for thisRow in CUSTOMERS, I use the formula:
ORDERS.Filter(Customer=thisRow)
Which returns a list of all the ORDERS rows that link back to this customer.
So it might be convenient to put that formula into a column in the CUSTOMERS table.
And that is exactly what the ‘back-link’ feature implements.
It creates a column called Orders in the CUSTOMERS table that uses that formula to provide a list of all the ORDERS belonging to that customer.
This is not normal practice in large-scale industrial relational databases, but it is common in no-code tools like Coda, Notion, Airtable, and others.
There is the possibility of a performance degradation as the database gets bigger over time. Each time you add a new row to ORDERS, it triggers a recompute of the formula in the Orders column of the CUSTOMERS table. And sometimes that can slow things down when there are a large number of rows.
However, I almost always use this reverse link technique because it allows us to show a customer’s orders as a sub-table in the customer dialog, which is a very useful UX feature that you get ‘for free’ in Coda.
➤𝖒𝖆𝖝