One person’s garbage is another person’s gold. I don’t see this needing a workaround unless you intend to flatten (denormalize) the data.
Let’s be honest, the record IDs exist because you wanted the data model to support relational connectedness, right? Now you expect Airtable to ignore that and give you something different when exporting said data.
Any database expert charged with the responsibility of reinstantiating your data model in a recovery Airtable crisis or in a new relational database system will need the record IDs, not the text representations. As such, the purpose of the exports should be clearly defined - is it for disaster recovery? Reuse in a spreadsheet?
It does actually, and by “better” I assume you mean different. The way I manage to create alternate export formats is to:
- Define the export requirements in the context of very specific requirements.
- Use the API or Script Blocks to build precisely the export format required.
Indeed, because in that context, it assumes you want the data, not a representation of the linking relationships (which should not be regarded as “garbage text”). More precisely, it’s not helpful for the use case you may have in mind.
But, if that use case is for disaster or crisis recovery and restoration, that garbage text is going to turn out to be little golden eggs.