|
|
|
Расчет цены и сортировка
|
|||
|---|---|---|---|
|
#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 |
|
||
|
|
start [/forum/topic.php?fid=32&startmsg=38923374&tid=1540409]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
148ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 249ms |
| total: | 509ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
