What are Coda’s DB structure and formula language most analogous to?

1

Brand new here, but invested the last 3 days in Coda videos, documentation, gallery, and trying things out.

I’m familiar with spreadsheets and old RDB design (not so much building and querying, yet, but design, yes). The many Coda tutorials I’ve watched, so far, seem to be either too basic, or too distant from my anticipated use cases to really help me start.

The schema series was great. I want more of that, and more detail, and more varied use cases with the formula tutorials. The Formula Fitness and accompanying docs with user exercises are invaluable, as is Coda’s text-based help documentation, but…

I feel I’m still missing a ton of ‘higher beginner / intermediate level’ design, schema, and formula basics, for how Coda works (at least for my intended uses). I want more confidence in the initial steps to design more varied DBs in Coda—in a bit more detail/depth than the schema series provides, and with broader examples.

Wondering if I learned about, e.g. NoSQL and formulas for that, if there’s better pre-existing literature (books, text problems) that are highly analogous, and might therefore make me more confident with how to best set up initial Coda tables and formulas. I still feel so unstructured in my options.

Any advice? Are there other systems that Coda is similar enough to that I could find a pre-existing learning text to help me find my bearings, more?

I’ll post docs and specific questions, soon, but this post speaks to what I want most—if an analogous-enough system even exists?

Thanks,
Courtenay

3 Likes
2

Hi @Courtenay_Ennis!

Welcome to the community :slight_smile:

Now that you’ve spent some time with the documentation, you’d be best served by building docs.

What do you want to build? There’s nothing quite like learning by building!

Also, what languages | frameworks are you already familiar with? I don’t know what RDB is, unfortunately.

Some things I have to recommend:

  1. Search the Coda community for the words “schema” and “structure” and read some of the posts. You’ll see lively discussion on how best to do doc structures.
  2. Follow @Paul_Danyliuk on YouTube and go through some of his videos. They are really deep
  3. Stop building a doc the moment you start to get tired of it. Then start rebuilding from scratch. That exercise will help you think about what happened that tired you out. Great for learning

As general doc recommendations:

  1. Use the same icon multiple times to visually signal doc structure and actions (not page meaning). So, use a mouse pointer symbol for anything related to selecting something, and a magnifying glass symbol for anything related to searching. The title of the page will tell what a page relates to, you don’t need the symbol. E.g. :point_up_2: Select Dates instead of :spiral_calendar: Select Dates
  2. Separate your source table into its own dedicated page, where all the columns are visible. Then make everything else a view of that table

That’s all I can think of for now. Play with the formula language a lot, here’s a good challenge if you’re up to it: Holiday challenge!

3 Likes
3

Hey and welcome to the Community!

Some self-promotion but check out my Best Practices Showcase doc and videos here:

It’s not the most compact series but it should give you plenty aha! moments.

I’m also doing a lot of livestreams lately. Many are public with replays on YouTube but some are private for patrons. Again, not the most concise form of content but at least it helped me get some knowledge across. First I was trying to record some lessons first but I was never happy with the results and never made them public.

Btw here’s the “secret” stream of Part 1 and I’ll stream Part 2 in a ~week, again, for patrons only (and maybe publish a month after that covertly like this one here, lol)

And to answer your question in the post — I don’t know of any existing course that would suit your needs but I hope to create one myself. So far it’s been going through these videos and streams but one day I’ll make it a concise straight-to-the-point syllabus.

2 Likes
4

Thanks, Connor! RDB = Relational Database.

I will start building and posting specific questions, soon. I will search ‘schema’ and ‘structure’ like you suggested–great tip!

Courtenay

5

Ahh, thanks Paul! Yes, I’ve been watching some of your content, and reading some of your posts. Your formula video looks very useful–I’ll check it out!

Best,
Courtenay

6

I just found a book on Data Modeling for MongoDB, and I think it might help.

Can anyone at @Coda1 confirm/deny what a good Data Modeling model might be with which to plan/build most elegantly in Coda?

Same question for formula language i.e. getting lots of practise with the formula language–is it highly similar to something else that I could find a good book on?

I know I need to ‘just try stuff and post questions,’ too, but… this is how I am, haha.

1 Like
7

it’s vaguely similar in spirit to lisp and wolfram language. I’m sure there are others

1 Like
8

Hi @Courtenay_Ennis!

From a Data Modelling perspective, a good approach for coda is actually the relational model (Relational model - Wikipedia).
MongoDB’s structure is document-oriented, meaning - in its context - that you have structured documents (in the form of binary JSON) rather than relational tables. I wouldn’t follow those principles if you want to use Coda.

As per the language, any language reference is a good starting point.

My warm suggestion is however to start form existing documents (in the Coda Gallery) and play around with them, along with the Coda Formula Reference

I hope this helps.
Enjoy!

2 Likes
9

Thanks so much, Federico! I’m actually a bit shocked to hear this re DB model–It sounds like you’re sure, but… Coda doesn’t seem like a traditional relational database to me, especially the way many of the examples I’ve checked out are set up?

e.g.

  • how you can just make fields multivalue at the drop of a hat with no need for a linking table
  • also the way Coda seems to say ‘calculated or concatenated columns in the master table are just fine’ (according to many example docs?)
  • also the 4 schemas and how they seem so adaptable–it feels like 'make one big multi-subject table, or lots of small ones, or whatever–feels more like NoSQL?

None of this feels like traditional RDB to me–seems to break so many rules of good RDB design?

But… I’m still happy about your response (just a bit sceptical?). I was reflecting earlier that one thing I still love about the relational model is that it’s so tangible–I can actually wrap my head around it (unlike how to elegantly design and scale up complex table relations in Coda, as of yet).

Anyway, maybe, based on your answer, I’ll return the expensive Data Modeling in MongoDB book I just bought… as long as you’re sure about this!

Thanks again,
Courtenay

10

HI Courtenay,

Welcome to Coda!

On a tangent, it seems like relational data base design and nomalising data is on the way out, and not just in Coda.

My 9-5 job is to do SAP S4/Hana implementations. It is one of the two largest ERP systems in the world - and they are radically denormalising their database. For example, financial postings are in a single table. In the traditional implementation, that would have been around 9 tables, plus indexes.

Which leads me to: I would suggest to focus on Coda, and not look for something analogous. It is just too different to anything else out there. It is very easy to get something worthwhile done, and then to gradually learn the areas that makes most sense for your specific scenario.

I have create some specific ways to link tables in this example doc:

Look for a page “Table Joins and Lookups”

But in general, keep to as few tables as possible.

2 Likes
11

Hi @Courtenay_Ennis,
in short, I agree on what @Piet_Strydom just said; also much in line with the message of playing around as much as you can in order to familiarise with Coda in the filed.

I didn’t mean to say that Coda is of follows RDBMS strict principles.
As a matter of fact, Coda is not a DB engine at all.
However, having relational perspective on how to model data surely helps a lot.
Especially for those (it might not your case, but it’s certainly very common) who come from a grid approach (spreadsheets).

Perhaps working on a specific use-case is the best possible approach to deal with data modelling, implementation and querying.

Cheers!

4 Likes
12

@Piet_Strydom and @Federico.Stefanato,

  1. Thank you both so much!
  2. Really appreciate the further clarification. @Federico.Stefanato, what you added really helps re RDB thinking, even though it’s not an RDB.
  3. This is all fascinating.

@Piet_Strydom, I’ve joined your community, too :slight_smile:

Two more questions on this topic, if I may.

  1. re

Fascinating! So… @Federico.Stefanato If Coda is not a DB engine at it’s core… what is it?

Further @Piet_Strydom, is it really that different from everything else out there? If so, curious why you think so. Maybe this is semantics. It seems analogous to some Google docs and sheets held together with scripting, or there’s Notion, also Airtable+apps? But… I do think Coda is the most elegant all-in-one version for people who don’t need a more clearly Airtable/RDBMS-like setup? (and I heard you, @Piet_Strydom, re ‘everyone is denormalizing’ so maybe Airtable is already becoming a bit moot?)

  1. re studying formula language: I’ve heard @Connor_McCormick1’s references to Lisp and Wolfram (thank you!)–I’m almost completely unfamilliar with formula writing (bit of Excel), though, so any additional specific suggestions might be really helpful.

I’ve just started Think Like a Programmer–anyone know it? I’m feeling might be a great move, as it should help me up my problem-solving and algorithmic thinking skills (from near zero, haha), regardless of specific language, which is something I can already tell I will likely need, but…

@Federico.Stefanato, if there are any specific languages you think would be most helpful/analogous, seeing as I’m starting at zero, anyway, I would love any specific suggestions. That way I can maybe find exercise books in that language (but @Piet_Strydom, I get your/everyone’s point about ‘just learn Coda’–noted, and… I will!).

Thanks so much again, everyone, for the answers. Incredibly helpful and clarifying.
Courtenay

13

HI Courtenay,

Thanks for joining the community! I am in the middle of moving countries while on a difficult project, so unfortunately I am neglecting it at the moment.

Re - Coda being different: Initially there was some talk about Coda being a replacement for spreadsheets - Ain’t gonna happen. Maybe the using Excel as a database scenario, yes.

I originally started with Notion, but there filtering mechanism was severely broken.

I also have worked (in a very limited way) with Access.

Coda has many things that are similar to all of the above, but:
Access - You can have keys to tables, and use foreign keys to build relationships between tables. You can build Queries, and join tables for reporting purposes. None of this works remotely the same way in Coda. There is also no data dictionary functionality in Coda.

Notion is relatively similar to Coda, but the implementation is very different, not least the filters. Notion also has the “page” idea inherent in every row, which is very different to Coda.

The closest that Excel comes to linking tables, is with the Vlookup function. But that works very differently to the Lookup functionality in Coda. Also, Excel functions follows the functional paradigm, while those of Coda does not, also Coda inherently works with columns in its formulas, as opposed to the cell-based method of Spreadsheets.

So while there is a lot of superficial similarities - a functional language, table manipulation, linking of tables in the different tools, how they are implemented works very differently.

As I am getting more experience in Coda, it is getting easier to “think” in Coda. It is becoming more natural to design a schema that works for Coda, whereas in the past I used to think in terms of joined tables.

BUT Coda is much more than that. It creates a completely new three dimensional way of building a document. This document is an example of what I mean with that.

At the heart of the data model of the doc is three tables. But when I think of the info in this document, my mental model is very far from tables, but much more three dimensional pages.

And this might be why @federico said that Coda is not a DB engine at all - it is a multi-dimensional document engine, which includes a component to manipulate data that is stored in tables.

For example, my blog Monie Orchards is done in Coda, but there is not a single table in there.

Regards
Piet

3 Likes
14

Thanks, Piet! I appreciate the extra time and detail, and I get it a lot more, now re ‘why Coda is different than conventional spreadsheets and databases when we look deeper.’

Sorry for not responding sooner–I either didn’t get notified or missed your response till just now.

Cheers,
Courtenay

1 Like
15

Update re Coda’s data model: Learned about this today from @maria and or @Rocky_Moon – this answered my question incredibly well–I think anyone trying to wrap their head around ‘how to understand Coda’s origins to better understand how to develop in it best’ might love this:

1 Like
16

Thanks for sharing Courtenay, this was very informative.

P

17

Woohoo! So glad you found that helpful @Courtenay_Ennis !

1 Like