Structural organizational tips for an employee database

[TamirN]

I want to build out an employee database. What I'm starting to run into is having 5000 fields in a single table, based off of employee name. There's a lot of data that doesn't need to be together, so while I can create 20+ different views, it seems like I might be overcomplicating things. Basically, I'd love to be able to have my employees as a record, and have different tables perhaps that all organize around the employee record.

For example:
Employee->Personal Info
Employee->Social Info
Employee->Employment History Info

What are some good ways of trying to organize this data? 

[Shannon_Bradley]

I would absolutely have at least 3 tables there, with a Primary and additional linked records. It will take some work, but you could duplicate the existing table twice, then work on each to remove fields that will be in the other ones. At the same time add link fields from the 2 new ones to the Primary one.

As an example: https://airtable.com/shrKp3OyAu8T7iWpI 

[TamirN]

This looks a bit like what I want, but I'm concerned with the record duplication. Every time I get a new employee, I would need to create them in all 3 tables manually (so, room for error) and THEN link them together. 

Maybe I'm thinking too much like a database?

[Shannon_Bradley]

Yes and no. I would work from the "main" table and just think of it as each table being a different page of info. 

Say you start entering your info on the main page, then when you get to the Table 2 field (ie Personal Info) you put in their name. Nothing exists so you click on 'Create New Record "Jane Doe""

This creates the new record in Table 2. Click on that directly and it brings up the Table 2 record info. You don't leave Table 1, just click on the new name button in the Table 2 column. Fill that new window in.

Click the X or just outside that window to close. Repeat that process with Table 3 (ie work history)

Now all of the pertinent information is in your database, separated into more easily managed sections. And you never really 'left' Table 1. The important thing is to remember that this is a relational set of tables, and everything connects.

[Christopher_Can]

I’ll just throw in here that while I do think the multiple tabs approach is valid, it starts to run into usability issues if the size of the base and functions continue to grow.

For example, I have a base built around 16,000 people and growing and the main tab has about 80 fields.  So yeah it’s a lot.  But I also have 15 or so other tabs in that base driving other processes linked to the entries in the first tab one way or another.

And that’s without getting into other bases with sync’d info from the main one.

All of this is to say: At a certain scale and as you continue to grow with Airtable, there is a degree of mindfulness required no matter what to remember how you have data displayed in useful ways.

I’ve personally always liked views more, for what it’s worth.  They aren’t as intuitive to initially access like tabs are, but I feel like managing data within a tab is more intuitive than across tabs and at a certain point there’s no more mindlessly access organized info without being purposeful about it anyway.