Hey @Sofian_Bayed!
I'm running out the door right now, so I'll be brief.
To speak plainly, fifty tables is an insane number of tables to have in a single database.
That signals a massive amount of technical debt and I'm willing to bet on more than one of these scenarios:
- You have separate tables for data that does not need to be fractured and siloed.
- You're not leaning on relationships between tables.
- You have dirty data that is not validated and is not consistently formatted.
I highly recommend that you go to the drawing board and really make sure you understand your data, data types, your record types, and the purpose of each of them before you continue any further.
Historically, when I've interacted with users and businesses that were spreadsheet-driven before interacting with Airtable, they end up wanting to mimic their old spreadsheets. This presents in them translating each sheet on their spreadsheet files into a table within Airtable.
I see this a lot.
The example tables above can probably be split into two bases. One base for sales, and the other base for project and task management with four clean, concise tables:
Food for thought.
Again, I'm running out the door and would write volumes on this matter if I had more immediate time.
That being said, feel free to provide any additional details about your data or what your use case is. I'd be happy to dig in and walk you through how you can better structure your data, because I presume you're at a point where your data is no longer working for you and is probably weighing you down with how bulky it all is.
Telling you about the Table Switcher (CTRL + J) won't resolve a serious underlying issue at the heart of your implementation.
