A family of Microsoft relational database management systems designed for ease of use.
You do not need 10000 tables.
You do not need 28 tables.
You need 3 tables!
One table will have 10000 records, one per unique ID. It can be populated using an Append query based on a SELECT DISTINCT query on your spreadsheet.
Another table will have 28 records, one for each of what you're calling a "record" - though it is far from clear to me what that might be. Let's call its primary key RecordID.
The third table will have one record for each unique combination of unique ID and your "record". I suspect that this table can be populated using a "Normalizing Union Query" based on your spreadsheet, something like
SELECT spreadsheet.UniqueID, "A" As RecordID, [A] As RecordValue
FROM spreadsheet WHERE [A] IS NOT NULL
UNION ALL
SELECT spreadsheet.UniqueID, "B" As RecordID, [B] As RecordValue
FROM spreadsheet WHERE [B] **** IS NOT NULL
UNION ALL
<for all 28 columns>
You may be in the spreadsheet mindset that you have only one grid of many columns crossed with many rows. That is NOT how relational databases work! Instead they're "tall and thin", with few fields and many rows.
Possible to post a more comprehensible example of your data, such as two or three rows of your spreadsheet or a nonconfidential description of the real world data that it models?