Клуб Яндекс.Расписаний

Предложение по форме поиска

В моем понимании, люди при покупке билетов ориентируются по двум показателям:

1. Дата прибытия/убытия (это важно если поездка приурочена к конкретному событию)

2. Цена путешевствия (если человек летит в гости к родственникам в другой город, или бизнесмену нужно слетить в регион проверить работу удаленных подразделений, поездку можно отложить на неделю-другую, если разница в цене билета составит несколько тысяч).

В настоящий момент поиск билетов, хоть и удобный - однобок, ориентирован на дату прибытия и убытия, что удобно не для всех пользователей. Добавив несколько несложных элементов фильтра и вариант выдачи думаю можно удовлетворить потребности оставшейся части.

Предлагаю рядом с датами "туда" и "обратно" добавить поле "+/-" со списком для выбора  1,2 или 3 недели и галочку "оптимизировать по цене". 

Затем модифицировать процедуру поиска таким образом, чтобы если галочка установлена, сначала выдавались наиболее дешевые билеты из всего указанного периода.

Еще больше заинтересуют посетителей оптимизированные по цене маршруты с пересадками. Например: билет на самолет Челябинск-Москва стоит намного дороже, чем Екатеринбург-Москва. На разницу вполне можно купить билет на поезд (причем есть электричка, которая приходит прямо в аэропорт Кольцово-Екатеринбург), и на оставшиеся деньги пить коньяк всю дорогу .


2 комментария
Да, все так. Но все это чрезвычайно сложно. Мы хотим сделать что-то подобное, но все запросы с ценой - чрезвычайно тяжелые запросы, а запросы с таким жонглированием цены - это вообще за гранью добра и зла.

Так что мы работаем над этим (с)
Существует целый кластер технологий решающих проблему тяжелых запросов.  Можно создать синхронную базу данных с более удобной структурой, можно создать систему привентивных расчетов - у вас же есть статистика запросов: по самым популярным направлениям при изменении цены на какой-либо билет посчитали самые дешевые маршруты и сложили в отдельную базу - пришел пользователь брать инфу по ценам - достаем не из основной базы, а из базы с привентивными расчетами. У Вас же наверняка пересадки привентивно просчитываются и расчеты куда-то кэшируются - не расчитываете же вы пересадки каждый раз по-новой. То же самое можно сделать в целях оптимизации по цене. Вобщем я это все к тому, что проблему с недостатком производительности можно обойти кэшированием или параллельной кэшированию технологией и технологии эти отработаны. Пожалуйста не бросайте - дело нужное. И если яндекс не сделает - вообще никто не сделает.