Why does coda distinguish between a page and a database entry? These are two completely different things to my understanding and it’s annoying because you always ask yourself:
Should I put it into a page or in a table?
On other systems everything is the same, for example in Notion everything is a page and on TiddlyWiki everything is a tiddler. You just put everything in a page (respectively in a tiddler) including metadata.
On Coda pages don’t have metadata and there are no ways to filter pages. You can only do this with tables. I think that this is made by purpose and I would be interested in the reasoning behind it.
I must say that have no idea how TiddlyWiki or Notion work but I’d say that Tables in Coda are where your datas should/could live if you wish to store and/or manipulate them and/or linked them to each others (as it could just be easier this way)…
A (sub)page is where you display your datas according to your need or a specific purpose (let it be a specific view of a base table, a chart, etc…)…
Airtable worked this way at some point in its existence too (few years ago), if I remember correctly…
All you had was bases (instead of tables) and it required a lot a work to display those bases for a specific purpose (at least, that was my experience in another lifetime… )
This is how I’ve come to use Coda over time : any piece of datas I have would go in one or more “work” table(s) in one or more “work” page(s) … as for the display of those datas once I’m done with the manipulation, I use views, controls, canvas formula on specific other “display” page(s).
Sometimes, if I just need to store a unique piece of data, I might store it in a canvas formula (or a canvas control) and re-use it where needed but if I need to manipulate that unique piece of data more than once and get more info from it, I don’t hesitate and use a one row helper table
But that’s just me
After that, a lot of how you build your doc would depend on its final goal … and as always, there are multiple ways to get to a result with Coda
This is not exactly true if you use a table and one or more canvas column
Metadata for the canvas column(s) would be what you have within the fields at the top level table (which you can then filter, etc …).
You are quite right, Coda has both tables and pages, but so does Notion. Coda also, as @Pch mentioned a third option, the canvas column. This is a column in a table that works like a page.
Use tables for lists: lists of people, lists of books, lists of anything for which you want to store the same characteristic. E.g. title, author, genre, publish date, etc, etc.
Pages are for non structured information, prose, images, etc
Canvas columns are handy to store repeated occurrences of unstructured information. For example, a table with a list of meetings. Date, topic, etc. But then in a canvas column, I store the minutes of the meeting.
These three basic objects can be mixed and matched. For example, in my meeting minutes column I always have views of two other tables. One where we can select the list of attendees of a meeting. The other where we can record the list of action items coming out of the meeting. Elsewhere in the doc, people have a view where they can filter out the action items they are responsible for.
This makes for a much more flexible environment than Notion.
