Weekly tip: Dubious tables vs views

When to use tables vs views in Airtable

Beginners to Airtable often get views vs tables confused.

Here’s a quick tip to see whether you should use tables or views

If each row of data represents the some type of object, you should keep everything in one view

Here’s a concrete example. If I’m tracking properties across states, I should NOT create separate tables for each state, since properties is the same type of object

Don’t do this

Don’t do this

Instead, combine all the rows into one table, and add a “State” column

A slightly more complex example.

Say I’m a venture capitalist tracking my deals in Airtable

My schema for Airtable is this

• Company (table)

  • Company name (field)

  • Size

  • ….

• 2. Investors/limited partners (table)

  • Name

  • Phone

  • Organization

  • Amount invested (number)

• 3. Contact (table)

  • Name

  • Phone

  • Organization

This is a very common schema I (Steven) have seen amongst VCs using Airtable. Upon further inspection, it’s apparent that table 2 and table 3 are pretty similar- 3 of the fields are the same!

So a better schema would be (new columns bolded):

• Company (table)

  • Company name (field)

  • Size

  • ….

• 2. Contacts (table)

  • Name

  • Phone

  • Organization

  • Type (select type with options “investor” and “regular contact”)

  • Amount invested if investor

At one point, I (Steven) worked on a team at Airtable to help solve this problem. We called the above example of dubious tables, and we used column/field similarity as a way to determine whether tables were dubious or not.

Both Chris and Steven have done numerous migrations like this away from dubious tables. Feel free to contact us if you need help on this. Or check out this in-depth article on how to do so here from Airtable support

Hope you find this tip useful!

Have a dubious table setup impeding your automation/base setup? Or need help more generally in your automation/Airtable/low-code setup? To work with us, contact us here