@Paul_Danyliuk 's awesome work on best practices for creating business docs are incredibly valuable. His not so little web-series on making a template is a great 8 hours to learn tonnes about data structure.
I’ve spoken briefly to paul on a couple of occasions about our own business doc. Its complicated. I built it 18-24 months ago when I knew very little about coda.
For simplicity, lets just talk about a simple project database.
Our current one works well enough, but it frequently breaks due to staff working on the database directly rather than with the use of secondary “helper” tables. We accept this - but when I re-build the entire thing (a massive undertaking for me since I still don’t really know all the dangerous pitfalls) we want to solve this as good as we can.
Very early on I developed a UX which allowed for people to see different things / their view mucking up the view of someone else (ie, selected project)
However, when it comes to helper tables, this becomes more complex.
It makes sense that first and foremost each user gets one row in each helper table.
However, what happens if two users select the same project info to edit. It is copied to the helper table where they can edit, but it will be the SECOND persons who hits save who’s edits actually end up being saved. The first person will save (and they’ll be copied back to the main database) but those changes won’t (cant) be seen by the second person editing.
I really don’t see any other way around this other than causing a project that is being edited to be “locked” for all other users in some sort of read-only mode.
And then run some sort of automation which unlocks / cancels editing after a time period so that someone doesn’t just leave the page after being distracted, only for that project to be un-editable.
Does this make sense? How are others approaching the multi-user case for helper tables?
Many thanks. Brendan.