It gets worse when you have to use more than one set because there is too much data to have full backup daily and you also need to index few incremental sets.
In my custom program & file database, I only use physical tape names, i.e. the names that I write on the labels of the cartridges. Either the program tells me what cartridge to load in the drive, or I inform it what cartridge I have loaded (e.g. for a new cartridge). I see no reason for a logical name. If I would ever copy a tape on another and I would discard the original tape, it would be trivial to substitute the name in the database.
Maybe for a large enterprise maintaining a comprehensive file database could be time consuming even in the best implementation, but I doubt it.
In my experience, keeping an up-to-date file database for about 120 TB of content that increases by about 10 to 20 GB per day still takes a negligible time.
While I have worked in a few large companies where a lot of data existed, in all small- and medium-sized companies (less than 100 computers) that I have seen there was less backup data than that (not counting things like standard disk images with the OS and with SW, which do not belong in periodic backups and which where shared, being identical for various classes of employees).
The file index is actually a relational database table with a lot of metadata about the files, including: position in the tape collection as tape number + file number, name, path name, modification time, length, content hash (to identify duplicates) and a set of keywords and tags, to be able to search for a file even when the name is not known, or to be able to retrieve sets of files.
The files written on the tape are grouped in compressed archive files, but the database with metadata is about the files inside of those archive files.
Obviously, the file index itself is also backed up regularly.