![]() |
|
Модераторы: skyboy |
![]()
|
|
| BuShaRt |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Есть следующая структура данных
![]() Есть предопледеленный список людей и действий. В базе мы храним события, которые включают в себя определенный набор действий, выполняемый определенным набором людей. Достаточно стандартная ситуация. Есть задача делать выборку по действиям и людям. На входе я получаю action_id и member_id (поэтому могу просто с помощью left_join присоеденить таблицы event_action & event_member к таблице event, после чего выполнить выборку по WHERE (в рамках 1 запроса естественно)). Но тут от рук-ва пришли данные, что это не лучший вариант, а надо поступить иначе. Мы делаем по запросу к таблицам event_action & event_member в результате получив 2 массива event_id, после чего на уровне выше (php, perl и т.д.) мы просто сравниваем массивы и оставляем только те id, которые есть в обоих массивах. К сожалению я не обладаю достаточным опытом, что обднозначно прокомментировать рациональность такого подхода, поэтому хотел бы услышать комментарии от более просвещенных коллег. Есть ли смысл в такой реализации? |
|||
|
||||
| Akina |
|
|||
|
Советчик ![]() ![]() ![]() ![]() Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 106 Всего: 454 |
Ответ зависит от конкретной системы. Но такой подход скорее всего имеет смысл лишь в том случае, когда селективность каждой из выборок высока, а стоимость трансфера данных от SQL-сервера к клиентской части мала. То есть - достаточно редко. Или если по требованиям безопасности информация о связи (таблица event) не может быть вынесена на сервер - ещё более редкий случай. Другое дело, что такой подход скорее всего идеологически ущербен - перекладывание выполнения элементарной операции на средство, которое для выполнения такой операции не оптимизировано. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| Zloxa |
|
|||
|
Чо? ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 33 Всего: 161 |
:yes Если селективность высока, т.е. в результат попадает малая доля исходного набора данных и оказывается целесообразным использование индекса, при таком подходе /*я думаю*/ движок врядли сможет эти индексы задействовать. мне кажется отдавать объединение на уровень выше - нелепо. Не смотря на то что mysql не поддерживает intersect, мне кажется его inner join должен бы таки отработать более эффективно нежели то же самое, но на php, perl и т.д.
Такой запрос сможет и задействовать индексы и вернет только те event_id которые будут возвращены обоими подзапросами. Здесь я закоментировал distinct. Я так понимаю что таблицы реализуют связь многие ко многим. Обычно эта связь подразумевает уникальность пар внешних ключей. Если ограничения на уникальность пар внешних ключей нет, distinct следует раскоментировать (или же вынести на уровень основного запроса, что мне кажется чуть менее целесообразным). Это сообщение отредактировал(а) Zloxa - 12.1.2012, 09:52 -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
|||
|
||||
| BuShaRt |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Действительно толковый запрос, но лучше ли он запроса, использующего Left join? Если это зависит от селективности, то какие какой из подходов выгоден при каких показателях селективности? Не каких требований по безопасности и т.п. нету, основное требование скорость обработки при высокой нагрузке. Кроме того списка ID мне будет достаточно (другие данные, такие как name мне не нужны) т.к. основные данные из таблицы event всегда кешируются в noSQL базе. Это сообщение отредактировал(а) BuShaRt - 12.1.2012, 09:58 |
|||
|
||||
| BuShaRt |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 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. Поиск события по участникам или действиям в рамках задачи не придусмотрен. Есть ли в этом смысл? |
|||
|
||||
| Zloxa |
|
|||
|
Чо? ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 33 Всего: 161 |
Еще раз повторю. Описанный тобой запрос с left join врядли сможет использовать индексный доступ по обоим предикатам. В лучшем случае - по одному, оракл по одному смог бы, мася - сомневаюсь. По обоим, боюсь я и оракла не заставил бы отобраться. Попробуй. Если таки сможешь задействовать оба индекса, то ничем не лучше. Это сообщение отредактировал(а) Zloxa - 12.1.2012, 10:48 -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
|||
|
||||
| BuShaRt |
|
|||
|
Эксперт ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 1391 Регистрация: 29.6.2006 Репутация: нет Всего: 6 |
Zloxa,
Ясно. А по поводу второго вопроса, что скажите? |
|||
|
||||
| Zloxa |
|
|||
|
Чо? ![]() ![]() ![]() ![]() Профиль Группа: Завсегдатай Сообщений: 3473 Регистрация: 12.9.2008 Репутация: 33 Всего: 161 |
Я не могу дать экспертной оценки данного ршения. Пробуйте. Практика - критерий истины. -------------------- Достоверно известно, что 89% людей доверяют статистике взятой с потолка |
|||
|
||||
![]()
|
| 1 Пользователей читают эту тему (1 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | MySQL | Следующая тема » |
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |