Table for locations with sublocations

Hmm, couple quick thoughts and notes…

• The thread you reference is quite old, and there have been significant changes (improvements!) in the function of parent/child records in the same table since. It might be perfectly functional for you to have child records inside a single locations table.
• Aside from doing same table linked records, if your overall Preserves table is very small and the real operative location is the sub-location, it could be managed by single select perhaps.

The real issue you’re going to have separating out Preserves and Preserves Sub-Location is you’ll end up passing information through additional lookup/rollup fields. That’s not a real problem per se, but it can potentially add complexity. 

How interesting! I actually started out with everything in one table before splitting them. I did a quick search on the help area for this topic. I found this one but we are currently operating under a free account.  Any further pointers on this?

We have over 50 preserves total, the seed collection list is about 10-15 unique locations including sublocations, outplantings have a similar number but they are not necessarily the same as the collection areas. There are several elements of this that are tricky for me [primary being this is a completely new platform and I have limited database-design building experience]:

• we have sub-locations that we want to identify in our seeds receiving table
• similarly, sometimes we have sub-locations we want to identify in our yet-to-be-built “restoration areas” on different preserves (this is the area I am actively building)

Thanks!

Multiple tables is definitely the way overall (and a personal maxim of mine for Airtable is the solution is always more tables haha), but sometimes when the data type is the same it’s good to consolidate tables where possible. When we’re talking about Locations and sub locations, those are the same type of data (locations) so it’s sometimes useful to keep them together. That said these days don’t expect to stay on a free tier very long. The more tables->more records->record limits for free plans. 

We have over 50 preserves total, the seed collection list is about 10-15 unique locations including sublocations, outplantings have a similar number but they are not necessarily the same as the collection areas. There are several elements of this that are tricky for me [primary being this is a completely new platform and I have limited database-design building experience]:

• we have sub-locations that we want to identify in our seeds receiving table
• similarly, sometimes we have sub-locations we want to identify in our yet-to-be-built “restoration areas” on different preserves (this is the area I am actively building)

Airtable is a great place to start with limited database design experience (it’s how I got started haha). The thing I’m thinking through is how your links are expressed… If you separate the Preserves and Sub-Locations tables, then you might need two linked record fields for your seeds receiving table (for those received at a Preserve w/ no Sub-Location, and another for those at a Sub-Location) whereas keeping the locations all in one table, with an inside table link for specifying sub locations means you could have a single linked record field from Seeds to Preserve which can specify a sub-location if it’s necessary. What I’m describing is laid out in the help document here

Fantastic! Thanks for sharing more of your thinking. I will check that document out and keep building and refining :) 

Airtable is a fantastic tool for beginning database building! I used Microsoft Access ages ago, designing one whole database with help, and this has been so much more fun comparatively speaking.