Structuring base complexity - best practices

Hi dear community,

I am a developer, quite experienced at using Airtable, and love best practices.
I never really had a need to post a message as the documentation and this forum are already full of precious infos. Thanks you all for that, especially members like @Bill.French - are you french by the way? :wink:

My problem concerns big structures for bases. It is not really a matter of slow performances, but rather a matter of human understanding and keeping a clean database.

I just got on a new project as a Product Manager, the main base contains 32 tables and some tables have almost 200 fields.

Obviously everything has been built through small fixes here and there, and there is no naming convention. I have a lot to learn about that and I am now looking into topics like this : database - Relational table naming convention - Stack Overflow

Problem I have :

  • Do these naming conventions fit an airtable usage ? Most of the people who are going to use my base are not developers. I want to have a clear convention for Table/Views/Fields naming
  • Airtable differs from a traditional database in various ways, it may not be the best approach to apply traditional standards
  • Is there some kind of documentation/article I can relate on concerning this topic?

I found these (unanswered) articles :

  • community.airtable : what-naming-convention-do-you-use/26721
  • community.airtable : enforced-naming-conventions-for-tables-and-fields/21772
  • community.airtable : views-management/15876

But also found this really helpful article :

Thanks @Eric_Goldman

Do you guys have anything to help with that?
Does the Airtable team have clear standards I should read? Even a book I should keep on my nightstand ahah?

Also, I am not sure when I should split my bases. At which point can we consider it counterproductive to have many tables? But also a loss for the data analysis to split it?

And finally, a practice they have at that new company is to use a few parameters I would use as single select as a whole new table (for exemple gender for a contact). There argument is to use that to work on the data. Do you consider it a best practice or who it be better to keep it as a single select and to work on the data using groups in a view for example?

Thanks in advance for you answer. I know it’s a long topic that could have been more synthetic, but am sure I am not the only one having this kind of questions.

Btw, are webinars or group meetings organised on these kind of topics? If so I would love to be a part of it. If not : who would be up to organise or join some with me?

1 Like