|
|
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Приветствую Вас, уважаемые форумчане! У нас есть такие таблицы: DISCOUNTS - reservation_from_date - reservation_to_date - from_date - to_date - coef - hotel_id PERIODS - reservation_from_date - reservation_to_date - from_date - to_date - hotel_id PRICES - period_id - sum Получается так что если ищем цены за определенный интервал, то к каждому результату нужно применить скидки (помимо таблицы скидок существуют много других, как надбавки, доп условия и тд). Результатов могут быть до 100 000, соответственно если применить скидки к каждому результату это сильно отразится на скорость выдачи. Считать заранее цены сложно потому что скидки могут быть активны сегодня но неактивны завтра, значит нужно каждый день пересчитать а это миллионы записей. Проблема в том что нам очень важна сортировка, мы можем сделать пагинацию но проблема со скидками, пока они не будут применены мы не знаем какая эта будет цена. Пожалуйста, подайте идею, в какую сторону двигаться, может у кого-то был подобный опыт? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 22:32 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgРезультатов могут быть до 100 000 Столько отелей ни в одном городе нет. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 22:46 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
В отелях есть разные типы комнат, питание, виды из номеров и тд, на один отель могут быть много результатов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 22:59 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgПолучается так что если ищем цены за определенный интервал, то к каждому результату нужно применить скидки (помимо таблицы скидок существуют много других, как надбавки, доп условия и тд). Результатов могут быть до 100 000, соответственно если применить скидки к каждому результату это сильно отразится на скорость выдачи. 100000 -- это не так уж и много, при правильной организации БД вполне можно всё сделать быстро. gnuorgСчитать заранее цены сложно потому что скидки могут быть активны сегодня но неактивны завтра, значит нужно каждый день пересчитать а это миллионы записей. Не верю, что миллионы. gnuorgПроблема в том что нам очень важна сортировка, мы можем сделать пагинацию но проблема со скидками, пока они не будут применены мы не знаем какая эта будет цена. "нам важна сортировка" -- ну так и в чём проблема ? Сортируй. gnuorgПожалуйста, подайте идею, в какую сторону двигаться, может у кого-то был подобный опыт? Прежде всего, объяснить задачу. Прежде всего -- себе. Я не понял, в чём проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 23:05 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgУ нас есть такие таблицы: DISCOUNTS - reservation_from_date - reservation_to_date - from_date - to_date - coef - hotel_id PERIODS - reservation_from_date - reservation_to_date - from_date - to_date - hotel_id PRICES - period_id - sum Ну и БД какая-то невменяемая, кто на ком стоял -- не понятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2015, 23:08 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Я не хотел напрягать вас разными тонкостями программы, но результатов реально много, даже если выдается 1000 результатов, все равно долго обрабатываються. Цена формируется примерно следующим образом: Интервал поиска 01.05.2015 - 10.05.2015 01.05 - 10$ - discount_1 - discount_2 + markup 02.05 - 10$ - discount_1 + markup 03.05 - 10$ - discount_1 + markup 04.05 - 15$ - discount_1 + markup ... + Доп услуги + трансфер + билеты за транспорт = цена за тур Собственно вопрос в том - Реально сложные расчеты производить в реально времени и отсортировать их или нужно все-таки рассчитать цены заранее и выдать готовую цену? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 00:01 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgMasterZiv, Я не хотел напрягать вас разными тонкостями программы, но результатов реально много, даже если выдается 1000 результатов, все равно долго обрабатываються. Цена формируется примерно следующим образом: Интервал поиска 01.05.2015 - 10.05.2015 01.05 - 10$ - discount_1 - discount_2 + markup 02.05 - 10$ - discount_1 + markup 03.05 - 10$ - discount_1 + markup 04.05 - 15$ - discount_1 + markup ... + Доп услуги + трансфер + билеты за транспорт = цена за тур Собственно вопрос в том - Реально сложные расчеты производить в реально времени и отсортировать их или нужно все-таки рассчитать цены заранее и выдать готовую цену? пока ничего нереального не вижу, попробуй напиши, не получиться - сделаешь то же самое в виде предрасчета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 00:42 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorg Реально сложные расчеты производить в реально времени и отсортировать их или нужно все-таки рассчитать цены заранее и выдать готовую цену? В первую очередь, определитесь могут ли у вас меняться цены на отель в течение дня? Или они фиксируются в некоторый час Х на день и в течение дня не меняются? Если второй вариант - очевидно, достаточно рассчитать единожды и не напрягать лишними пустыми расчетами при каждом запросе. Если первый вариант - очевидно, что вы не можете однократно рассчитать скидку, т.к. в противном случае у вас будут неактуальные данные для пользователей. Так же определитесь как будет работать приложение по времени: 8(12)х5(7) или 24х7? gnuorg...к каждому результату нужно применить скидки (помимо таблицы скидок существуют много других, как надбавки , доп условия и тд). Чем принципиально скидка отличается от надбавки, кроме как знаком перед суммой? ИМХО, разделять их не хороший вариант. gnuorgСчитать заранее цены сложно потому что скидки могут быть активны сегодня но неактивны завтра, значит нужно каждый день пересчитать а это миллионы записей. Пересчитывать надо только те скидки , статус которых изменился на момент расчета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 09:50 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorg, Для начала схему покажите - так лучше воспринимается. Потом объясните цели и задачи. А то непонятно за что боретесь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 11:39 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
А какая СУБД ? зы: Наверно какое-то убожество типа sqlite или Mysql ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 12:15 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgЯ не хотел напрягать вас разными тонкостями программы, но результатов реально много, даже если выдается 1000 результатов, все равно долго обрабатываються. Даже на евробукинг если задать число людей, время и город ты не получишь больше сотни-двух вариантов. Потому что их физически больше нет. Если у тебя 1000, да ещё и работает медленно, это значит, что во-первых, критерии слишком нечёткие, а во-вторых, обработка построена из рук вон криво. Поэтому, как уже сказали, показывай реальные структуры данных и примеры обработки. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 12:40 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Указал ниже ссылка на картинку со схемой, простите что связи не указал, не разобрался еще в navicat-e. ссылка на изображение Я знаю что там проблемы есть, в структуре и стыдно такое показывать. авторА какая СУБД ? СУБД - PostgreSQL Пробовал, писал даже скрипты расчетов на питоне, компилил и использовал в запросах, надеясь на какой-то прирост производительности, но проблема в том, что можно отсортировать цены за тур только после того как рассчитал все существующие цены и делать пагинацию в таком случае бессмысленно. автор критерии слишком нечёткие Согласен с Вами, но клиент хочет чтобы отображались все что есть в базе на указанный интервал, ему удобнее смотреть самые дешевые цены. Расчет примерно таков: Интервал поиска 01.05.2015 - 07.05.2015 Extrass discount сидит 7 дней - платит за 6 01.05 - 10$ - discount - discount 2 - discount 3 03.05 - 10$ - discount - discount 2 - discount 3 04.05 - 10$ - discount - discount 2 05.05 - 15$ - discount 2 06.05 - 15$ - discount 3 07.05 - 15$ - discount 3 + доп условия + трансфер + билеты за транспорт = цена за тур Соглашусь с автором: Mikle83Пересчитывать надо только те скидки, статус которых изменился на момент расчета. Как вы посоветуете, тратить по больше времени и сделать расчеты за ранее или производить их каждый раз при поиске? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 18:16 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgУказал ниже ссылка на картинку со схемой, простите что связи не указал Забей на картинки, пость SQL скрипт с CREATE TABLE и FOREIGN KEY. Он намного нагляднее и даёт больше информации. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 18:38 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorg, Лично у меня ссылка не открылась. Да и если там нет связей, то толку от нее никакого. Храните уже готовый расчет, так будет проще. Хотя и на лету считать тоже можно. Эх, студенты ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 18:56 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Совершенно отстойная схема. Неудивительно, что она не работает. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 19:55 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
авторСовершенно отстойная схема. Неудивительно, что она не работает. Спасибо за ответ, буду очень признателен если перечислите пару серьезных ошибок в структуре базы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 20:02 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Ошибка первая и главная: информация слишком размазана по разным таблицам. Собери цены в одну таблицу, а поправки к ним в другую. Всё не относящееся к расчёту - вынеси вон. Тогда считать будет легко даже для мускуля. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 20:10 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorg, Увидев поля varchar(0) могу посоветовать автору бежать оттуда. Хотя нет, пусть потребует больше денег и все завалит. Хотя всеравно завалит. Ну а потом уже и убежать можно попытаться. Если не умеете что-то делать - не беритесь. Ну не всем же быть космонавтами ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 22:15 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgMikle83Пересчитывать надо только те скидки, статус которых изменился на момент расчета. Как вы посоветуете, тратить по больше времени и сделать расчеты за ранее или производить их каждый раз при поиске? Так там еще вопросы были, исходя из которых выбор варианта будет очевидным: а) Можете ли вы (согласно бизнес требованиям) зафиксировать скидки на день и не менять их в течение дня? Будут ли данные актуальными? б) как предполагается пользоваться приложением? Будет ли таймаут, когда никто не пользуется БД (к примеру, в 20-00 все ушли домой и закрыли офисы). Если оба ответа "да" - то имхо считать однократно ночью, когда все спят. Если хотя бы один ответ "нет" - то вариантов слишком много, а вводных данных от вас слишком мало. Но в таком случае 100% надо вводить понятие "актуальные" данные и пересчитывать только то, что изменилось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 22:15 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Mikle83Так там еще вопросы были, исходя из которых выбор варианта будет очевидным Судя по обрывкам информации, у него БД какого-то бюро путешествий, где туры планируются задолго вперёд. Поэтому никаких изменений скидок быть не может. Как и предпросчёта всех вариантов на годы вперёд. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2015, 22:19 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgПолучается так что если ищем цены за определенный интервал, то к каждому результату нужно применить скидки (помимо таблицы скидок существуют много других, как надбавки, доп условия и тд). Результатов могут быть до 100 000, соответственно если применить скидки к каждому результату это сильно отразится на скорость выдачи. Считать заранее цены сложно потому что скидки могут быть активны сегодня но неактивны завтра, значит нужно каждый день пересчитать а это миллионы записей. Проблема в том что нам очень важна сортировка, мы можем сделать пагинацию но проблема со скидками, пока они не будут применены мы не знаем какая эта будет цена. Пожалуйста, подайте идею, в какую сторону двигаться, может у кого-то был подобный опыт? Не понятно - в чем проблема то? Я так понял, что задача заключается в том, чтобы при расчете тура надо сказать клиенту сколько он заплатит за нужный ему период , при этом предложив разные варианты. Ну так в чем проблема- выбирайте стоимость для каждого отеля на каждый день нужного периода, выбирайте скидки на этот же период для этих же отелей и задача то в общем несложная. Ну и потом сортируйте уже результаты выборки. Что вас затрудняет? Написание запроса, ессено, будет зависеть от СУБД. Если под ораклом- то там есть интеллекутальные запросы- там вообще можно чудеса творить. Хотя для вашей задачи это в общем то не нужно. Ограничивайте поиск нужным периодом- и тогда записей будет не миллионы. Если вы это делаете по всем записям - сомнительная задача. И еще замечание по схеме - на мой взгляд в ценах должен быть не update (судя по полю updated_at), а insert (вы же собираетесь хранить всю историю изменения цен? Ну и такая же история по скидкам). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 04:53 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovПоэтому никаких изменений скидок быть не может. Как и предпросчёта всех вариантов на годы вперёд. Ошибаетесь - вполне могут быть изменения и цен и скидок- единственное нельзя делать перерасчет по уже заключенным договорам. В них останется старая цена и старая скидка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 04:55 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
авторСудя по обрывкам информации, у него БД какого-то бюро путешествий, где туры планируются задолго вперёд. Поэтому никаких изменений скидок быть не может. Как и предпросчёта всех вариантов на годы вперёд. Скидки могут меняться каждый день. Проблема с предпросчетом в том что мы не знаем на сколько дней клиент может заказать тур. интервал от 3 до 30 дней. Если хранить готовые цены за каждый день из интервал то получится примерно столько записей: 300 отелей * 10 типов комнат * 365 дней в году * 27 дней (интервал проживания) = 29 565 000 цен (на самом деле их гораздо больше) Вот столько нам нужно рассчитать каждый день (если не перерасчитать только те цены и скидки которые были редактированы). Второй вариант перерасчета это за каждый день а не за кол. дней проживания в отель - 300 отелей * 10 типов комнат * 365 дней в году = 1 095 000 цен. Этот вариант мне больше нравится но тут тоже есть проблема, я не могу применить скидки к каждому дню потому что в скидках есть минимальное кол. дней к которым применяется скидка. Тоесть пока я не знаю кол. дней которое выбрал клиент я не могу применить к нему скидку. авторОшибаетесь - вполне могут быть изменения и цен и скидок- единственное нельзя делать перерасчет по уже заключенным договорам. В них останется старая цена и старая скидка. Вы правы, даже удаление отеля никак не затрагивает уже существующие договора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 09:32 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgПроблема с предпросчетом в том что мы не знаем на сколько дней клиент может заказать тур. интервал от 3 до 30 дней. Помоему вы еще сами не представляете даже какую задачу собираетесь решать. Можете описать юзкейс- как вы собираетесь использовать цены и скидки? Каким образом на даты вы собираетесь выходить? Если вы с этим разберетесь- все встанет на свои места. Мне кажется клиент когда обращается- он хотя бы какие то параметры говорит: либо даты начал-конца, либо без уточнения даты- чтобы стоимость была минимальная. И в том и в другом случае есть выход на более краткосрочный период. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 09:44 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Я написал про предпросчет, цены рассчитанные уже в базе клиент получает только результат, во время получения результата никакие операции расчета не производятся. Поэтому пока клиент не произвел поиск я не знаю что он хочет, поэтому за ранее нужно просчитать все возможные комбинации. Клиент конечно выбирает дату заезда в отель, кол ночей, регион, отель... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 09:53 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorg, Bi-temporality в полный рост, но не берите в голову это определение... Все ваши условия по скидкам/наценкам можно преобразовать в "интервальные" условия, типов которых будет не так много. К примеру, "количество дней проживания от ... до ... скидка ...", "количество проживающих от... до ... скидка". "Интервальные скидки" будут так же зависеть от временного периода + фиксироваться от даты заказа. Все это позволяет проводить ежедневный перерасчет, и оперативно выдавать клиенту нужную информацию. Клиент указывает только значение интервальных параметров (к примеру, количество дней проживания - 7), после чего для каждого номера на указанные даты подтягивается заранее рассчитанная "интервальная скидка". Для дальнейшего развития темы - основной вопрос к ТС : у вас база уже готова (и вы ее меняете) или вы ее проектируете с нуля? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 10:16 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgКлиент конечно выбирает дату заезда в отель, кол ночей, регион, отель... Ну и почему не брать цены и скидки на указанный диапазон дат? gnuorgПоэтому пока клиент не произвел поиск я не знаю что он хочет, поэтому за ранее нужно просчитать все возможные комбинации. И поэтому вы хотите ему показать все отели на свете, все даты на несколько лет вперед и т.? Как можно что то считать, если вообще ничего неизвестно? Посчитать стоимость за период "на лету", со скидкой, без скидки нету никаких проблем. Повторю- определитесь с юзкейсом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 10:21 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Поддержу совет про "определиться с юзкейсом". В частности может помочь простой эксперимент. Представьте, что у вас нет базы, а есть просто информация о всех ценах и скидках на бумаге. К вам приходит клиент и что-то требует. Что вы будете делать? Что-то мне подсказывает, что в любом случае вы как-то попытаетесь ограничить объем бумаг для перелопачивания. В реальной жизни никто не будет молотить все варианты, если они не нужны. Поняв как нужный вам процесс должен происходить в жизни, где там больше всего работы и потерь времени, можно будет понять и то, что можно автоматизировать. Слона лучше есть по частям, в смысле не нужно сразу пытаться просчитать все возможные варианты, т.к. львиная доля ваших расчетов просто никогда не потребуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 10:41 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
авторНу и почему не брать цены и скидки на указанный диапазон дат? На данный момент так и работает, все считает на лету. Расчеты написаны на руби, около 5000 строк, и сделано по идиотски что эти 5000 строк выполняются для каждого результата. Я имел ввиду, если за ранее просчитать все, забить готовые цены в базу и выдать клиенту то что он просит то тогда нужно расчитать все возможные комбинации а их очень много. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 11:12 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorg300 отелей * 10 типов комнат * 365 дней в году * 27 дней (интервал проживания) = 29 565 000 цен (на самом деле их гораздо больше) Вот столько нам нужно рассчитать каждый день На самом деле их гораздо меньше, поскольку не во всяком отеле 10 типов комнат, а клиент не меняет комнату каждый день. Лично мне решение видится следующим: в ядре три таблицы (календарь, цены комнат, периоды действия скидок). Конечная цена рассчитывается влёт простым запросом с двумя JOIN и одним GROUP BY внутри. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 11:25 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgЯ имел ввиду, если за ранее просчитать все, забить готовые цены в базу и выдать клиенту то что он просит то тогда нужно расчитать все возможные комбинации а их очень много.если за бить, то можно и заранее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 11:25 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Mikle83 Все ваши условия по скидкам/наценкам можно преобразовать в "интервальные" условия, типов которых будет не так много. К примеру, "количество дней проживания от ... до ... скидка ...", "количество проживающих от... до ... скидка". Вы правы, наша проблема в том что мы никак не готовим данные перед расчетами от этого тратится много ресурсов. Спасибо вам большое, Mikle83. авторесли за бить, то можно и заранее слишком простое решение )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 11:52 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Вы, gnuorg, решаете неблагодарную задачу: пытаетесь формализовать рекламно-маркетинговое дерьмо. Она по определению не имеет хорошего решения. Я бы, наверное, сделал так: таблица с предрасчётами для максимально возможного количества вариантов плюс оперативные расчёты для того, что плохо формализуется. > тогда нужно расчитать все возможные комбинации а их очень много Все - не нужно. У вас есть набор входящих ограничений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 12:12 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorg, Никто весь ваш список с пагинацией смотреть не будет, поэтому предварительно расчитывать надо только стоимость т.н. пакетных предложений, напр.: Код: plaintext Далее вам нужна процедура подбора варинатов , которая реализуется в приложении и на каждом шаге выдает немного вариантов, тогда и расчетов будет на 5—6 порядков меньше, чем вы думаете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 15:46 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
авторНикто весь ваш список с пагинацией смотреть не будет, поэтому предварительно расчитывать надо только стоимость т.н. пакетных предложений, напр.: Воронеж, 3* , 2 чел., 7 дней 6 ночей, даты заезда, доп.услуги, цена, период продаж В таком случае вы сразу сможете предложить клиенту нечто внятное: он выбирает город и прмерное время, а вы показываете ему список. Вариантов обозримое количество, все фиксировано, легко сортируется и т.п. Мы хотим сделать что-то типа - http://www.tez-tour.com/search.html У них по умолчанию поиск работает на все отели, это очень удобно когда пользователь хочет смотреть самые дешевые цены по всей стране. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 19:17 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgэто очень удобно когда пользователь хочет смотреть самые дешевые цены по всей стране. Думаешь, пользователь поедет на экскурсию в Мухосранск вместо Питера только потому, что там отели в два раза дешевле?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 19:21 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Насчет России не знаю, но когда летят в Болгарию или Турцию то 90% пользователей ориентируются на цену. Есть такое понятие как ранее бронирование или СПО. Если заранее заказываешь тур, можешь сэкономить до 30% на отель или СПО когда заказываешь тур в конце сезона. Бронируете заранее когда знаете когда у вас отпуск. А еще часто бывает что 5* дешевле чем 4* поэтому пользователи хотят смотреть туры по всем категориям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 20:42 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Насчет России не знаю, но когда летят в Болгарию или Турцию то 90% пользователей ориентируются на цену. Есть такое понятие как ранее бронирование или СПО. Если заранее заказываешь тур, можешь сэкономить до 30% на отель или СПО когда заказываешь тур в конце сезона. Бронируете заранее когда знаете когда у вас отпуск. А еще часто бывает что 5* дешевле чем 4* поэтому пользователи хотят смотреть туры по всем категориям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2015, 20:46 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorgМы хотим сделать что-то типа - http://www.tez-tour.com/search.html У них по умолчанию поиск работает на все отели, это очень удобно когда пользователь хочет смотреть самые дешевые цены по всей стране. Вы на свой идеал-то внимательно смотрели? Если указана только страна, они показывают именно то, что я предлагал показывать вам — предварительно расчитанные пакетные предложения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.04.2015, 00:57 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
gnuorg, Добрый день. Так получилось, что я занимаюсь подобной задачей. Только в моей задаче на цену влияет возраст. Но смысл все тот же. Из 100000 предложений, чтобы сделать сортровку приходится проводить много расчетов исходя из количества гостей каждого возраста. Я бы хотел предложить вам списаться в скайпе и т.п. Чтобы вместе решать сложные задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2015, 20:54 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
ArtemeeyЧтобы вместе решать сложные задачи. Бугагага ))) Сложные задачи ))) Элементарный запрос надо было написать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.05.2015, 23:03 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Serguei, Скорее всего (вернее 100%) вы не поняли вопроса. Обычный запрос с join будет работать ограниченное время существования сайта. При росте сайта он перестанет справляться с нагрузкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2015, 16:28 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
SergueiArtemeeyЧтобы вместе решать сложные задачи. Бугагага ))) Сложные задачи ))) Элементарный запрос надо было написать Предложите решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2015, 16:30 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Artemeey, Весьма глубокомысленно. Запрос отрабатывает СУБД а не сайт. Поэтому к "росту" сайта даже и незнаю каким боком прилепить ваше замечание. Но продолжайте дальше. Решение предлагается только при условии что озвучены цели и задачи, есть все выкладки по расчетам и пр. А предлагать сферического коня в ваккууме - не смешно. Более того, подобные задачи решаются за деньги и не с наскоку. Поэтому тут могут лишь "пнуть" в правильном направлении. Ну а дальше уже как получится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2015, 20:17 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Злой Бобр, я вот тоже не понял, ни в чем сложность, ни в чем проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2015, 23:28 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Я понял в чем проблема gnuorg несколько раз упоминает о "дешевых ценах", например, " хочет смотреть самые дешевые цены по всей стране ". Цены могут быть низкими или высокими, но не "дешевыми". Поэтому и запросы отказываются быстро работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 13:05 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
А в чем проблема считать "на лету"? С какой стати это должно быть медленным? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 14:33 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Arm79А в чем проблема считать "на лету"? С какой стати это должно быть медленным? Вопрос очевидно в оптимизации запросов к БД. Если нужно пересчитывать МНОГО данных на лету - будет грустно. Иногда имеет смысл хранить промежуточные итоги (агрегаты) и вместо постоянного пересчета 100500 строк исходных данных дергать именно их (агрегаты). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 15:07 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
DarkMasterArm79А в чем проблема считать "на лету"? С какой стати это должно быть медленным? Вопрос очевидно в оптимизации запросов к БД. Если нужно пересчитывать МНОГО данных на лету - будет грустно. Иногда имеет смысл хранить промежуточные итоги (агрегаты) и вместо постоянного пересчета 100500 строк исходных данных дергать именно их (агрегаты). Да не, это понятно. Но я не вижу оснований постоянно что-то рассчитывать. Указываем интервал времени. Определяем гостиницы, цены, скидки, акции и т.п. Все это фактически один запрос. Если есть индексы - все должно летать. Где же тут предрассчитанные итоги? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.07.2015, 15:11 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Arm79Все это фактически один запрос. Если есть индексы - все должно летать. Где же тут предрассчитанные итоги? Не зная структуру метаданных базы - это гадание на кофейной гуще получается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.07.2015, 09:43 |
|
||
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#18+
Arm79, Попробую описать проблему более подробно: Параметры тура (строка в БД) - таблица `tours` - Максимальное число Взрослых - Максимальное число детских мест - максимальное число дополнительных взрослых мест (например в 2-х местном номере добавляется 1 спальное место) - максимальное число дополнительных детских мест (например в 2-х местном номере добавляется 1 детское спальное место) - Возраст ребенка, до которого тур бесплатный и место не считается (например дети до 2 лет) - Детский возраст (возраст с которого человек должен платить как за взрослого, например 16 лет) Стоимость тура за сутки (строка в БД) - таблица `prices` - стоимость детского места - стоимость взрослого места - стоимость дополнительного взрослого места - стоимость дополнительного детского места Делается выборка по таблице туров на основе входных данных: - Число взрослых - [+ возраст ребенка]{может не указываться или указываться несолкьо} - Период (две даты) Предполагаемое решение: Сначала фильтруем по таблице туров. Для каждого тура отдельно высчитывается НЕОБХОДИМОЕ количество взрослых и детских мест (у каждого тура возраст детей может отличаться (до 1, 2, 3, ..., 17 или 18 лет), не во всех турах дети до 2 лет размещаются бесплатно). В условии учитываются дополнительные места и их тип (взрослый или детский). По полученном списку туров начинаем получать стоимость этого тура - просчитываем фактическое число взрослых мест (N1), детских мест (N2), дополнительных взрослых мест (N3) и дополнительных детских мест (N4) - по этим числам делаем выборку SUM(`price`) по периоду из табилцы `prices`. Так как у каждого типа размещения своя стоимость - то и запрос будет состоять из нескольких частей: -- SUM(стоимость взрослого места * N1) за период -- SUM(стоимость детского места * N2) за период -- SUM(стоимость взрослого дополнительного места * N3) за период -- SUM(стоимость детского дополнительного места * N4) за период Итоговая стоимость - это и есть сумма тура. Каждый отель имеет свои требования и ограничения, по этому уйти от таких условий не представляется возможным. - Например посчитать стоимость для Взрослого и 16 ребенка НЕЛЬЗЯ как стоимость для двух взрослых (если у отеля детский возраст считается до 18 лет и детские места имеют отличную цену, чем взрослые) - Например посчитать стоимость для Взрослого и 16 ребенка НЕОБХОДИМО как стоимость для двух взрослых (если у отеля детский возраст считается до 15 лет) Сложность запросов И так, допустим мы делаем вывод по 10 туров (далее подгружаются по мере скролла страницы или прохождению по страницам): Тогда поиск туров займет = ВРЕМЯ_НА_ПОИСК_10_ТУРОВ_ПО_УСЛОВИЯМ_ВМЕСТИМОСТИ + ВРЕМЯ_НА_ФОРМИРОВАНИЕ_ЦЕН_ПО_ВХОДНЫМ_ДАННЫМ_ДЛЯ_ПЕРВЫХ_10_НАЙДЕННЫХ_ТУРОВ А теперь представим ситуацию, что нам надо сделать сортировку по цене: Тогда поиск туров займет = ВРЕМЯ_НА_ПОИСК_ВСЕХ_ТУРОВ_ПО_УСЛОВИЯМ_ВМЕСТИМОСТИ + ВРЕМЯ_НА_ФОРМИРОВАНИЕ_ЦЕН_ПО_ВХОДНЫМ_ДАННЫМ_ДЛЯ_ВСЕХ_НАЙДЕННЫХ_ТУРОВ Если у нас на сайте 100-200 туров, разница почти не заметна. Если же у нас их несколько десятков тысяч - то поиск будет занимать много времени. Индекса стоят на колонках, участвующих в условиях. Но проиндексировать цену не получится, так как число возможных вариантов цен очень велико (число взрослых может меняться от 1 до 20, число детей может меняться от 1 до 20, вдобавок у каждого тура детский возраст разный, число доп. мест для каждой выборки разный и зависит от настроек каждого тура, период может быть разный от 2 до 30 суток). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2016, 04:03 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1540409]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
80ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
88ms |
get tp. blocked users: |
1ms |
| others: | 233ms |
| total: | 451ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...