Возвращаясь к исходному вопросу, объединения - это то, что базы данных делают .Если они не могут делать соединения хорошо, они терпят неудачу на рынке.Таким образом, вы обнаружите, что любой из вариантов, обсуждаемых здесь, будет быстрым.
Обратите внимание, что «пользователи» - это зарезервированное слово в Oracle - вы, вероятно, хотите назвать свою таблицу как-то иначе.Также обратите внимание, что вы будете вызывать ошибки в исходной формулировке, если в адресах пользователя есть несколько записей.Обычные объединения просто вернут вам несколько строк.
Используя мои собственные таблицы с разумным индексированием и объемами данных, планы объяснения были:
Оригинал
SELECT STATEMENT ALL_ROWSCost: 226 Bytes: 390,570 Cardinality: 39,057
2 TABLE ACCESS BY INDEX ROWID TABLE X83109.FN_AR_INVOICE Cost: 2 Bytes: 13 Cardinality: 1
1 INDEX UNIQUE SCAN INDEX (UNIQUE) X83109.I_FN_AR_INVOICE Cost: 1 Cardinality: 1
3 TABLE ACCESS FULL TABLE X83109.FN_AR_LINE_ITEM Cost: 226 Bytes: 390,570 Cardinality: 39,057
Либо ANSI Join (как указано выше), либо традиционный Oracleсинтаксис, показанный ниже
select users.username as username, addresses.state as email from users, addresses where users.username = addresses.username;
SELECT STATEMENT ALL_ROWSCost: 377 Bytes: 898,311 Cardinality: 39,057
3 HASH JOIN Cost: 377 Bytes: 898,311 Cardinality: 39,057
1 TABLE ACCESS FULL TABLE X83109.FN_AR_INVOICE Cost: 149 Bytes: 333,788 Cardinality: 25,676
2 TABLE ACCESS FULL TABLE X83109.FN_AR_LINE_ITEM Cost: 226 Bytes: 390,570 Cardinality: 39,057
Так что нет большой разницы.Вы можете свободно использовать объединения, а также следить за производительностью.