Вот есть у меня таблица пользователей с кучей разных тарифов и опций, но главное разделение - это платные и бесплатные. Суть в том, что мне для построения определенного отображения данных надо сделать выборку одних и других, отсортированных по дате регистрации и некоторым прочим параметрам, исключая некоторых и т. д.
Вариант в тупую - выполняется два запроса, который будут выбирать пользователей платных и бесплатных, а потом по мере надобности подчитывать одних и других, как требует того алгоритм построения отображения.
Вот мне подумалось, а не быстрее ли будет завести отдельную(ые) таблицу(ы) для того, чтобы каждый раз при изменении состояния основной таблицы пользователей заносить туда все данные для построения отображения, так чтобы их можно было получить простым запросом с минимальными сортировками и условиями where?
Чуть позже я подумал, что избыточность эта не есть хорошо, а вот если сделать view'шки, с заранее отобранными пользователями, даст ли это какое-нибудь ускорение по сравнению с обычными запросами каждый раз при построении отображения?
Спустя 15 минут (5.09.2009 - 19:11) glock18 написал(а):
Думаю, вам стоит решить, насколько часто будет обновляться эта таблица. Каждое обновление - это дополнительный insert/update. Возможно вам следует просто проиндексировать уже существующую таблицу?
Спустя 51 минута, 7 секунд (5.09.2009 - 20:02) bvn написал(а):
Индексы по сортируемым полям - это обязательно. Обновления: регистрация пользователя - обновление, оплата - обновление (впрочем тут может быть отдельная таблица), изменение любых настроек - обновление.
Вопрос, есть ли смысл сделать вьюшку? Дают ли они ускорения относительно внешних запросов или эффект будет таким же?
Вопрос, есть ли смысл сделать вьюшку? Дают ли они ускорения относительно внешних запросов или эффект будет таким же?
Спустя 4 часа, 2 минуты, 50 секунд (6.09.2009 - 00:05) Nikitian написал(а):
Представления являются некими костылями, которые направлены на что угодно, кроме ускорения выборок (имхо, основывающееся на том, что встречал на практике).
Покажите запросы, структуры таблиц с общими порядками количества записей и частоты их обновления - по этим данным можно будет сказать как сделать оптимальнее.
Покажите запросы, структуры таблиц с общими порядками количества записей и частоты их обновления - по этим данным можно будет сказать как сделать оптимальнее.
Спустя 1 час, 51 минута, 16 секунд (6.09.2009 - 01:56) FatCat написал(а):
| Цитата (bvn @ 5.09.2009 - 19:56) |
| Вариант в тупую - выполняется два запроса |
Я бы сделал еще тупее: один запрос, и в цикле по строкам заполнение двух массивов... Это если для таблицы, размер которой измеряется единицами мегабайт.
Если же таблица на десятки или сотни мегабайт, наоборот, получал бы первым запросом количество строк в таблице, дальше цикл по 1000 или сколько там нужно строк со всеми сортировками в запросах, и разборка массивами по кускам.
Спустя 6 часов, 12 минут, 58 секунд (6.09.2009 - 08:09) Sylex написал(а):
| Цитата (bvn @ 5.09.2009 - 21:56) |
| а вот если сделать view'шки, с заранее отобранными пользователями, даст ли это какое-нибудь ускорение по сравнению с обычными запросами каждый раз при построении отображения? |
очень вряд ли.... и слишком мало данных для анализа - показал бы пример на практике показательный. Так можно еще больше абстрагироваться, и хранить "временные таблицы" в сессии )
Спустя 2 часа, 7 минут, 31 секунда (6.09.2009 - 10:16) bvn написал(а):
Спасибо всем за мнение. Пока за неимением опыта прислушаюсь. Особенно понравилась идея с двумя массивами.
Показать структуру еще не могу - идет этап начального проектирования проекта.
Показать структуру еще не могу - идет этап начального проектирования проекта.