Database structure design

1169 2
Showing results for 
Search instead for 
Did you mean: 
4 - Data Explorer
4 - Data Explorer

Hi !

Our company is working with Airtable for almost a year now, and I believe it can provide everything we need from a CRM / Dashboarding tool. But as our company grows, our Airtable base also is…  and we’re at the point of needing to evaluate the database structure because I believe it will become a bit of a mess when we grow and continue this way...  So I would like to reorganize the database and also build a lot of interfaces on top of that, so I don’t want to break up the database structure afterwards… 😉


So before changing it all, I’m looking for some advise and best practices on how to design a structured Airtable base which can grow and develop along with our company. More specific: right now I’m looking for some guidelines to when to separate or combine a grid to keep data in a structured way and maintaining flexible as our organization grows and our processes and needs change along.


I appreciate some general guidelines, but a description of our base and a more specific question follows beneath. Thank you in advance for taking time to help out here 😊


Our case:

For example: we now have different tables for “Projects”, “Work in progress”, “Accounts” and “Ideas”. But looking at the basic structure of these topics, they are all joined tables of the same kind (joining Customers, Colleagues, Goals, and Actions). The only difference lies in the focus (short/long term, internal/external, agreed list/working list) or in the stage (Idea/work in progress; an Idea can become a Project, Work in progress or Account).

I would expect that it is best to combine grids as much as possible, and use views and interfaces to look at de data needed for a particular question. But our processes are also developing quite rapidly, so it could be possible that we develop different needs for different types of work (let’s say: we need different features ‘registration of comments’ for “Projects” and ‘registration of mail’ for “Accounts”). Of course this is a simple example, but I can imagine that different needs will pull these “Projects” and “Accounts” apart again in future, because a combined grid will become huge and leads to other problems…

Secondly, there will be even more wishes from Airtable, like a Backlog for technical bugs and features, Value streams and Internal Processes, Marketing & Communication, regulation lists, Customer journey,  managing deadlines of all types, (optimization of) workflows, management information / dashboarding.... They are not there yet, and will go in new grids, views, or interfaces.

To make a long story short, I’ll be happy to hear your best practices, so I can make a good decision for our database structure. Thanks a lot!

2 Replies 2
7 - App Architect
7 - App Architect

In my understanding, what you're asking for is a broad consultancy-level advice. The scenario you describe scopes well beyond a simple request of "best practices".

For your immediate needs ("best practices", "when to separate or combine a grid...") you should research on your own within the site and you'll get interesting design guidelines, both from people's aportations and support articles.

Your case exposition sounds to me as a "growing company" in need of two things:
· Transit from a 'Pro' account to an 'Enterprise' account, in order to get the premium support it will need.
· Hire a consultant with expertise in database architecture (not specifically in automation, programming, interface design and such technical stuff) who is able to advice on big design decisions over an expanding environment like yours.

So I'd consider going 'Enterprise' and / or reposting this request on the 'Job Board' sub-forum.

4 - Data Explorer
4 - Data Explorer

Thank you for your reply and suggestions!

I'll dig into this and take next steps from there 🙂