Модераторы: skyboy
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Один запрос с Left join или два запроса без него? Как лучше? 
:(
    Опции темы
BuShaRt
Дата 11.1.2012, 18:29 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1391
Регистрация: 29.6.2006

Репутация: нет
Всего: 6



Есть следующая структура данных
user posted image
Есть предопледеленный список людей и действий. В базе мы храним события, которые включают в себя определенный набор действий, выполняемый определенным набором людей.
Достаточно стандартная ситуация.

Есть задача делать выборку по действиям и людям. На входе я получаю action_id и member_id (поэтому могу просто с помощью left_join присоеденить таблицы event_action & event_member к таблице event, после чего выполнить выборку по WHERE (в рамках 1 запроса естественно)). Но тут от рук-ва пришли данные, что это не лучший вариант, а надо поступить иначе. Мы делаем по запросу к таблицам event_action & event_member в результате получив 2 массива event_id, после чего на уровне выше (php, perl и т.д.) мы просто сравниваем массивы и оставляем только те id, которые есть в обоих массивах.
К сожалению я не обладаю достаточным опытом, что обднозначно прокомментировать рациональность такого подхода, поэтому хотел бы услышать комментарии от более просвещенных коллег. Есть ли смысл в такой реализации?
PM MAIL   Вверх
Akina
Дата 11.1.2012, 21:33 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Советчик
****


Профиль
Группа: Модератор
Сообщений: 20581
Регистрация: 8.4.2004
Где: Зеленоград

Репутация: 106
Всего: 454



Цитата(BuShaRt @  11.1.2012,  19:29 Найти цитируемый пост)
Есть ли смысл в такой реализации? 

Ответ зависит от конкретной системы. Но такой подход скорее всего имеет смысл лишь в том случае, когда селективность каждой из выборок высока, а стоимость трансфера данных от SQL-сервера к клиентской части мала. То есть - достаточно редко. Или если по требованиям безопасности информация о связи (таблица event) не может быть вынесена на сервер - ещё более редкий случай.
Другое дело, что такой подход скорее всего идеологически ущербен - перекладывание выполнения элементарной операции на средство, которое для выполнения такой операции не оптимизировано.



--------------------
 О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума.

PM MAIL WWW ICQ Jabber   Вверх
Zloxa
Дата 12.1.2012, 09:38 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 33
Всего: 161



Цитата(Akina @  11.1.2012,  21:33 Найти цитируемый пост)
когда селективность каждой из выборок высока

:yes
Цитата(BuShaRt @  11.1.2012,  18:29 Найти цитируемый пост)
На входе я получаю action_id и member_id (поэтому могу просто с помощью left_join присоеденить таблицы event_action & event_member к таблице event, после чего выполнить выборку по WHERE (в рамках 1 запроса естественно)). 

Если селективность высока, т.е. в результат попадает малая доля исходного набора данных и оказывается целесообразным использование индекса, при таком подходе /*я думаю*/ движок врядли сможет эти индексы задействовать.
Цитата(BuShaRt @  11.1.2012,  18:29 Найти цитируемый пост)
Мы делаем по запросу к таблицам event_action & event_member в результате получив 2 массива event_id, после чего на уровне выше (php, perl и т.д.) мы просто сравниваем массивы и оставляем только те id, которые есть в обоих массивах.

мне кажется отдавать объединение на уровень выше - нелепо. Не смотря на то что mysql не поддерживает intersect, мне кажется его inner join должен бы таки отработать более эффективно нежели то же самое, но на php, perl и т.д.
Код

select t1.event_id
from 
  (select /*distinct*/ event_id from event_actions where actions_id = :actions_id) t1
  ,(select /*distinct*/ event_id from event_member where member_id = :member_id) t2
where t1.event_id = t2.event_id

Такой запрос сможет и задействовать индексы и вернет только те event_id которые будут возвращены обоими подзапросами.
Здесь я закоментировал distinct. Я так понимаю что таблицы реализуют связь многие ко многим. Обычно эта связь подразумевает уникальность пар внешних ключей. Если ограничения на уникальность пар внешних ключей нет, distinct следует раскоментировать (или же вынести на уровень основного запроса, что мне кажется чуть менее целесообразным).

Это сообщение отредактировал(а) Zloxa - 12.1.2012, 09:52


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
BuShaRt
Дата 12.1.2012, 09:50 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1391
Регистрация: 29.6.2006

Репутация: нет
Всего: 6



Цитата(Zloxa @  12.1.2012,  09:38 Найти цитируемый пост)
Такой запрос сможет и задействовать индексы и вернет только те event_id которые будут возвращены обоими подзапросами.

Действительно толковый запрос, но лучше ли он запроса, использующего Left join? Если это зависит от селективности, то какие какой из подходов выгоден при каких показателях селективности? Не каких требований по безопасности и т.п. нету, основное требование скорость обработки при высокой нагрузке. Кроме того списка ID мне будет достаточно (другие данные, такие как name мне не нужны) т.к. основные данные из таблицы event всегда кешируются в noSQL базе.

Это сообщение отредактировал(а) BuShaRt - 12.1.2012, 09:58
PM MAIL   Вверх
BuShaRt
Дата 12.1.2012, 10:13 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1391
Регистрация: 29.6.2006

Репутация: нет
Всего: 6



Не знаю на сколько вовремя, но у меня возник еще один вопрос... Я хотел организовать его отдельной темой, но начав описывать, полян, то он очень тесно переплитается с этим.

Есть ли смысл вынести таблицы event_actions и event_member на уровень noSQL? Хранить по ключу event_id сереализованные массивы соответствующих значений, по форме:
event_id = { member_id1, member_id2, member_id3 }
event_id = { member_id3, member_id4, member_id1 }
Получаеться, мне надо выполнить следующий действия:
1. 2 запроса к noSQL базе
2. Дересилизация 2 массивов
3. Сравнение 2 массивов

Сразу хочу уточнить, что:
1. Изменение данных не являеться узким местом и я могу себе позволить выделить любое кол-во ресурсов на процесс подготовки данных, в то время как на выборку нагрузка следует минимализировать.
2. Поиск события по участникам или действиям в рамках задачи не придусмотрен.

Есть ли в этом смысл?
PM MAIL   Вверх
Zloxa
Дата 12.1.2012, 10:33 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 33
Всего: 161



Цитата(BuShaRt @  12.1.2012,  09:50 Найти цитируемый пост)
но лучше ли он запроса, использующего Left join?

Еще раз повторю. Описанный тобой запрос с left join врядли сможет использовать индексный доступ по обоим предикатам. В лучшем случае - по одному, оракл по одному смог бы, мася - сомневаюсь. По обоим, боюсь я и оракла не заставил бы отобраться. Попробуй. Если таки сможешь  задействовать оба индекса, то ничем не лучше.

Это сообщение отредактировал(а) Zloxa - 12.1.2012, 10:48


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
BuShaRt
Дата 12.1.2012, 10:40 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
***


Профиль
Группа: Завсегдатай
Сообщений: 1391
Регистрация: 29.6.2006

Репутация: нет
Всего: 6



Zloxa, 
Ясно. А по поводу второго вопроса, что скажите?
PM MAIL   Вверх
Zloxa
Дата 12.1.2012, 10:47 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Чо?
****


Профиль
Группа: Завсегдатай
Сообщений: 3473
Регистрация: 12.9.2008

Репутация: 33
Всего: 161



Цитата(BuShaRt @  12.1.2012,  10:40 Найти цитируемый пост)
 А по поводу второго вопроса, что скажите? 

Я не могу дать экспертной оценки данного ршения.
Пробуйте. Практика - критерий истины.


--------------------
Достоверно известно, что 89% людей доверяют статистике взятой с потолка smile
PM   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | MySQL | Следующая тема »


 




[ Время генерации скрипта: 0.0481 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.