Hello,
I am using database design principles to set up my tables in Coda. For example, instead of having all the attribute/field columns to describe a contact in the contact table, I’ve created separate tables for phone numbers, emails, addresses, etc. since a given contact can have multiple of each (one-to-many).
The challenge with this is setting up the UI/UX. Do I use text boxes directly in the canvas for user input along with a submit button that will do multiple actions like create entries to all the tables? The problem I see with this is the scalability. I will have several pages with many text box inputs and the management of them will be difficult.
What would be a better way to handle the UI/UX aspect given my backend set up?
I do it a bit differently and like this, all in one table with contac types and a creation date to retrieve the most recent (the last) value via a filter
Oh wow, thanks Christiaan. I see that a contact can be entered multiple times as a row depending on the contact type info to be entered (email, phone, etc).
I didn’t even consider having a column set up like contactDetails to hold fields that would typically be separate columns/tables. Are there any drawbacks or limitations?
there are no limitations, Coda is a row based application unlike spreadsheets and the column types like email and link are confusing from this perspective.
once you know how to filter, you have to make sure you always take the most recent one based on the creation date or the activation date (in case somebody moves from address one to address two, it is the date the change becomes effective you have to calculate with).
it requires a bit more reflection, but I work like this all the time and so I keep my tables simple, easy to update and i am sure I always get the most recent value.
Friday, March 8, I realised I wrote a blog about his principle.
