grey3's Journal

SQL vs NoSQL: а как всё-таки лучше?
asinitsyn > "Как DBA с опытом,"
>zamotivator > "3. Я программист, который занимается разработкой движков СУБД"
Хочу задать вопрос одновременно ОБОИМ собеседникам: как в реляционных СУБД, например MySQL, эффективно решить заданный в посте

rainman_rocks "Зачем NoSQL программистам" пример: эффективно извлечь несколько записей с подзаписями-списками?

Например, в турбюро на веб-страничке надо показывать маршруты вместе с датами. Дат у маршрута, понятное дело, может быть сильно переменное количество - от нуля до сотни. У каждого маршрута есть длинное описание, его тоже надо показать.
1. Тупое решение в лоб - запросить сначала список маршрутов с описаниями, и в цикле для каждого запрашивать даты к нему (поскольку это отдельная связанная таблица). Для N маршрутов понадобится N+1 запросов, что слишком "дорого" по времени.
2. Тупое обходное решение: в 1 запросе дублируем данные о маршруте в каждой строке. Строится JOIN, результат GROUP BY, и просто игнорируем маршрут и повторное его описание для каждой следующей даты того же маршрута, выдавая описание однократно лишь в момент смены маршрута. Но если данных о маршруте много - опять получаем сильный перерасход времени и памяти на ненужное многократное дублирование информации.
3. Сложное обходное решение в 2 запроса: запросив сначала список маршрутов, далее запрашиваем общий список дат для этих маршрутов, используя IN (вложенный SELECT). Далее по второму запросу строим в памяти списки дат к каждому маршруту (то есть хеш списков), и в процессе обработки первого запроса добавляем к нему соответствующий список. Получаем экономию времени базы, но тратим время и память (причём примерно столько же сколько в варианте 2) на составление списков.
4. Полемическое решение: заменяем MySQL на NoSQL, выдающий готовые JSON-строки маршрутов с массивами дат, и передаём их через AJAX прямо в броузер пользователя - пусть клиентская машина занимается рендерингом. Экономим и на базе, и на обработке.

Какой новый, улучшенный вариант могут предложить DBA с опытом и разработчик движков? Или хоть аргументировано поддержать один из первых трёх вариантов?
Почему бы разработчику движков не сделать, как минимум, возможность при обработке запросов с GROUP BY выдать специальное значение группируемого поля "смотри выше" (аналогично спецзначению NULL)? А ещё лучше, сделать расширение, способное эффективно извлекать массивы/списки из связанных таблиц в одном запросе с основной таблицей?