Well I was going to suggest exactly this after your original post (assuming you are the same anonymous), but then convinced myself that this could not be what you intended. This scheme will work just fine if all you want is an external reference to be used like an index for rows in another table. The caveats to this scheme is important to note (should you still want to do this): 1. It will be a LOT (orders of magnitude) slower than a normal index because it isn't an Index, it is an external indexed lookup which requires subsequent re-lookup into the real index (the rowid of the data table). 2. It becomes outdated the moment any CRUD operation happens on the data table and then has to be rebuilt (and perhaps re-dstributed) 3. Even if re-making and distributing the new index is fast and efficient, there will always be a time-frame within the index and data will be mismatched. If a lookup is done during this phase, a client system can request data for say "John Smith" and end up getting the record for "Joan Smythe" which requires internal revalidation of obtained data, and even then, if the client can "know" it is not the right data it received, what is it to do in that case? Just wait x amount of time? Report non-function to the user? Perhaps you could "version-control" your index files. Either way, you will need to add so much work in checking mechanisms around all this to ensure system integrity. Is it really worth the saving of not having the index included in the data?