Ah, so it's not really a "menu", it's a node tree of some sort.
But hmm, if you're trying to make your code generic, then I think you're pushed to a solution that involves storing table name and key. It's not clear to me why this is going in a database at all, why not just store the table name and key in the HTML, but pursuing that question would surely just get me even deeper into what your application is all about. (Well, maybe you build this big tree once and keep it, rather than refiguring it on the fly with each display. Again, without knowing more, I can't judge the relative merits.)
But my first idea based on your description is that the data you need is a table name and a key field, with the key field defined as varchar and big enough to hold any possible key. If you want to support files with multiple fields making up the key, I'd define multiple key fields.
At that point a foreign key specification is hopeless, which is potentially a drawback to this implementation. Any referential integrity would have to be maintained in code instead of magically by the database.
On the other hand you could index on the key easily -- there's only one. And the table would be small and simple.
The other obvious implementation is what you originally discussed, making a separate field in the "reference" table for each possible destination table. But if you're trying to make this generic, that means the table layout would be different for every implementation, and could potentially have a huge number of fields. What if there are fifty target tables? Well, disk space implications are probably less than one might fear as a null field takes very little space -- I recall reading a discussion on the internals of some DBMS that said a null field took only one bit, in a set of "null field flags" at the beginning of each record. (I forget which database that was. Maybe mySQL. I don't mess with that kind of internal enough to remember which was which until I have to look at it again.) Code to process it would have to loop through all the fields to find the non-null one. You create the possibility of a program bug creating a record with two non-null fields, which is then difficult to interpret.
Frankly, I think both these solutions suck, but I can't think of a better one. If anyone else on this forum has a better idea, I'd be interested in hearing it myself for future reference.