The limit is 50,000 per base, not per workspace. Keep in mind that if you try to put the data back together in a single base using synced tables, all the records in the synced table still count towards the 50,000 record limit.
You can try splitting up unrelated data into different bases. What types of interaction would you need between the different bases?
You could have a synced table from the [sales] base that syncs only recent sales to the [inventory] and [clients] bases, and then run automations to decrease inventory and create clients based on recent synced transactions.
The limit is 50,000 per base, not per workspace. Keep in mind that if you try to put the data back together in a single base using synced tables, all the records in the synced table still count towards the 50,000 record limit.
You can try splitting up unrelated data into different bases. What types of interaction would you need between the different bases?
You could have a synced table from the [sales] base that syncs only recent sales to the [inventory] and [clients] bases, and then run automations to decrease inventory and create clients based on recent synced transactions.
Well, currently, there’s a link field in my Sales table that I use to mark a book sold. So when I select that book in the Sales table, it automatically gets its status in the Books table updated to “Sold.” Is that kind of automation possible across bases just using Airtable? Or would I need to bring something like Zapier into the mix?
Well, currently, there’s a link field in my Sales table that I use to mark a book sold. So when I select that book in the Sales table, it automatically gets its status in the Books table updated to “Sold.” Is that kind of automation possible across bases just using Airtable? Or would I need to bring something like Zapier into the mix?
It sounds like you are currently selecting a linked field to specify which book is sold. If your Inventory] and ]Sales] are in different bases, you will need a different method of identifying what book is sold. You will not be able to pick from a linked field. You will have to manually type in the identifier for the book (or copy/paste from the inventory table).
Once you have a unique identify for each book that will be the same across both the hSales] and ]Inventory] bases, you can have the book in the nInventory] table marked as sold when a new sale occurs for the book. If each sale can include multiple books, you will also need to a new way of indicating multiple books in the sales record.
Other considerations include how are you doing data entry? Is all data entry manual?
There are multiple ways of doing this, including using Zapier, or also using synced views and automations. Here is one way:
Have a unique code for each book that can be used across both bases and is each to remember or look up.
When you make a new sale, create a new record in the nSales] base. Have a filtered view that only shows recent sales.
Create a synced table in the nInventory] base that shows the recent sales. Make sure to have it delete records that are deleted in the source.
In the nInventory] base, have an automation that triggers off the synced table. Have the automation use the unique book code in the sales record to update the corresponding inventory record.
There are a lot of details that will need to be worked out. For example, if you have multiple books in the same sale, you may need to use a scripting automation to parse out the individual books. It is also possible to make things simpler if you use the record id of the book inventory as the book code that you enter in the nsales] record.
How many records do you create per week or months? It’s much easier to have both tables in the same base.