В общем, лучший способ справиться с такого рода требованиями - это использовать первичный ключ (или фактически любой удобный, компактный уникальный идентификатор) в качестве «указателя» и полагаться на индексированный поиск, который будет быстрым - что он обычно будет.
Вы можете использовать ROWID в большем количестве СУБД, чем просто в Oracle, но обычно это не рекомендуется по ряду причин. Если вы уступаете школе разработки баз данных «каждая таблица имеет столбец автоинкремента», вы можете записать значения столбца автоинкремента в качестве идентификаторов.
У вас должен быть хотя бы один индекс (почти) для всех ваших таблиц - этот индекс будет для первичного ключа. Исключением может быть таблица, которая настолько мала, что легко помещается в память, не будет обновляться и будет использоваться достаточно, чтобы ее нельзя было извлечь из памяти. Тогда индекс может быть отвлечением; однако такие таблицы, как правило, редко обновляются, поэтому индекс ничего не повредит, и оптимизатор проигнорирует его, если индекс не поможет (а может и не поможет).
У вас также могут быть вспомогательные индексы. В системе, где большая часть активности читает данные, вы можете захотеть ошибиться, если у вас будет больше индексов, чем меньше, потому что время доступа является наиболее критичным. Если ваша система требовала интенсивного обновления, вы бы использовали меньшее количество индексов, потому что с обновлением индексов при добавлении, удалении или обновлении данных связана стоимость. Очевидно, что вам нужно спроектировать индексы, чтобы они хорошо работали с запросами, которые фактически выполняют ваши пользователи (или ваши приложения).