Hello,
We have a rolodex system that I am considering refactoring a bit and I’d like to make sure the approach is sound. Basically a common need we are starting to see is to have base tables for certain things, like companies or people, that need to be worked with in different contexts with different additional information and processes.
What’s the best practice for extending a table with additional information? In programming a typical example would be in database where you might have an account table with very basic information like id, email, and then additional tables for context-specific information about that account, like account settings, or account login links, etc.
I believe the main way to do this in Coda would be with additional tables that have a lookup to the base table, and then add any additional information needed for that other context.
I put together an example of this to illustrate and perhaps help others, but I just wanted to see if there are any big problems with this approach or other, better approaches that I am overlooking. Thank you!
1 Like
Hi @Ed_Liveikis ,
thanks for sharing this!
Your approach is definitely helpful.
It’s a topic I tried to discuss in the past (have a look at this, if you wish: [Open Discussion] An Object-Oriented approach for Tables: Extensions).
Unfortunately, this solution isn’t resolving the problem from the other way round: the polymorphic advantage of an extension.
Think about more structured hierarchies, for instance:
People < Candidates
People < Employees < Interviewers
People < Contact < Client
People < Contact < Provider
With the composition approach you provided, there would be a multiple nested structure, i.e. every subsequent extension should flatten the set of attributes (columns).
A pure extension would just add the missing attributes.
That way you could define the datatype of the lookup by narrowing / expanding the proper table and implicitly would have the full set of (un-nested) attributes.
Interviews
- Candidate: Candidate
- Role: Employee
- Interviewers: Interviewer
- References: Contact
- ...
Allowing something like:
ListCombine(Interviewers, References, Candidate)
.FormulaMap(CurrentValue.Name).BulletedList()
I hope this add some ideas to talk about.
Thank you!
1 Like
Hi @Federico_Stefanato , thanks for the response.
Yes actually I was wondering about something like that, in fact I posted earlier on this thread about things that took a long time to discover in coda, even though looking back it’s quite obvious, but I thought that Views might work that way - that Columns added on a View would “extend” the base table, not be added to it.
Thanks for linking your post - I did search but did not find that one. The big downside I’m having right now with the approach I mentioned is what you described - that I want the base table to be updated with new entries if something is entered in one of the extended views. Currently, the user will have to enter new entries into the base table and then any other extension tables needed for a contextual view…which is not great.
I was trying to use pre-filled form fields + RunActions for this, but without a published form and I’m not sure if the form fields can be used to populate lookups. I wonder if a Form that would allow entering a row into multiple tables at once would make sense (wouldn’t help with cross-doc though…but it would be a start).