2015-04-14 5 views
0

Я унаследовал некоторый старый код SQL со следующим фрагментом (я анонимно для простоты).SQL Join Table vs. Select

CREATE EXTERNAL TABLE dim_abc (user_id int) 

CREATE TABLE dim_foo AS 
SELECT user_id, 
     ... 
FROM my_table a 
JOIN (SELECT * FROM dim_abc) b 
ON (a.user_id = b.user_id) 

Вместо того, чтобы ...

FROM my_table a 
JOIN dim_abc b 
ON (a.user_id = b.user_id) 

Любая идея, почему предыдущий разработчик сделал бы ВЫБРАТЬ внутри JOIN?

** Код - это улей.

+0

Посмотрите на разницу двух утверждений. Создают ли они разные таблицы? Только я могу думать о том, что subselect может подавлять параметры определения таблицы, которые разработчик не хотел наследовать в новой таблице. –

+1

Многоточие немного путает вещи. Его трудно сказать, если они делают рекурсию, или если это два разных оператора, разделенных эллипсисом. Не могли бы вы опубликовать весь код? – paqogomez

+0

Хорошая статья SO, посвященная этому http://stackoverflow.com/questions/7194547/nested-select-statment-in-mysql-join – WorkSmarter

ответ

3

Версия без подзапроса лучше по целому ряду причин. Некоторые базы данных (вы не упоминаете базу данных) потеряли бы способность использовать индексы на dim_abc из-за подзапроса.

Это не ваш вопрос, однако. Лучше всего предположить, что код стал более сложным. Теперь dim_abc может потребовать дополнительной логики в один момент времени. Поскольку код был упрощен, конечным результатом был бесполезный подзапрос в предложении from. Это просто догадка, но она предлагает один правдоподобный сценарий.

+0

Есть ли преимущества в производительности от НЕ использования подзаголовка? – user2715877

+0

Они должны быть эквивалентными, хотя возможно, что более длинная версия подделывает синтаксический анализатор/оптимизатор, который не распознает его как базовую таблицу. Что-то вроде этого могло пойти в любом случае и могло быть даже намерением. Я ничего не знаю о Уеве и, скорее всего, соглашусь с Гордоном. – shawnt00

+0

@ пользователь2715877. , , Большинство баз данных будут генерировать один и тот же план выполнения для двух запросов. Однако MySQL (и связанные с ним БД) материализуют подзапрос, вызывая проблемы с производительностью. Однако это не MySQL, потому что другое ограничение заключается в том, что подвыборки не допускаются в предложении 'from' для представления. –