Сложная выборка по Дате

[wowkaster]

Здравствуйте!
В одном из моих начальных проектов у меня возникла трудность с вычеслением даты, по сложным критериям.

Есть отель.
Все цены в отеле деляться на 3-и сезона.

High: 15.05 - 20.09
Middle: 25.04-15.05 and 21.12-20.01
Low: 20.09-20.12 and 20.01-25.04

так вот, когда человек бронирует номер в приделах одно сезона, никаких проблем нету.
Но когда же бронь происходит между сезонами, возникают сразу же трудности.
А ещё больше трудностей возникают когда человек бронирует и пересекает грань смены года.

Допустим с 15.05 по 20.09 никаких проблем, (20-15)= 5 * (на цену за сутки), получаем суму.
19.09 по 25.09, уже есть некоторые моменты, мы считаем 1-н день в высоком сезоне, и 5-ть в низком.

Есть немного не понятнки как создать условия если человек бронирует с 25.12 по 05.01,

Как лучше сделать выборки и сравнения дат, если известен только день и месяц. Год должен сам подставятся. везде подставить date("Y") явно нечего не даст ))) и дураку думаю понятно

 

[С.]

Найти абсолютную начальную дату, затем запустить цикл, добавляя по одному дню, анализирую каждый день и его стоимость. Это не совсем эффективно по скорости, за то значительно облегчит алгоритм расчета и управление им.

P.S. Не забывать, что считаются ночи, а не дни.

 

[wowkaster]

а как быть через год?

Ведь есть только жосткие правила день.месяц, но ведь 20.12 по идее меньше чем 05.01 (следующего года)

 

[Welcome]

Я бы использовал все в unix timespamp'e там проще... Может не правильно и опытные люди подскажут вариант лучше?

 

[AmdY]

если дата окончания меньше, чем дата начала, значит он находится в следующем году. но не понятно, почему бы не указывать год явно.

 

[С.]

почему бы не указывать год явно.

Чтпбы не корректировать эти данные ежегодно.

 

[KorP]

но ведь 20.12 по идее меньше чем 05.01 (следующего года)

я может ещё не проснулся, но - какая разница больше или меньше? главное что бы введённая дата входила/не входила во временной отрезок 21.12-20.01
мне видится самый простой вариант брать каждое число, проверять вхождение и считать ссуму, в цикле

 

[wowkaster]

я может ещё не проснулся, но - какая разница больше или меньше? главное что бы введённая дата входила/не входила во временной отрезок 21.12-20.01
мне видится самый простой вариант брать каждое число, проверять вхождение и считать ссуму, в цикле

Не совсем понимаю.

Если судя из того что 21.12 и 20.01 это флоат, до 21.12 больше чем 20.01, другой же вопрос если всё перевести в юникс с использованием года, то алгоритм должен знать когде добавлять к date('Y') + 1, а когда не трогать, так ведь?

Скорей всего можно решить сверив, последние 4-и цыфры, если равны то работаем штатно, если нет, то к последней цифре добавляем 1-цу, но это как по мне костыльное решение.

 

[KorP]

у меня перегрев от температуры, но почему бы не взять просто эти отрезки:
01.01-20.01
20.01-25.04
25.04-15.05
15.05-20.09
20.09-20.12
21.12-31.12

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

 

[С.]

Если судя из того что 21.12 и 20.01 это флоат, до 21.12 больше чем 20.01

Какой в жопу флоат? Строки это! А для сравнения поставить в порядке [год-]месяц-день нельзя разве? Ну неужели такие элементарные вещи надо разжевывать?

 

[wowkaster]

Какой в жопу флоат? Строки это! А для сравнения поставить в порядке [год-]месяц-день нельзя разве? Ну неужели такие элементарные вещи надо разжевывать?

Вы адекватны?

 

[antson]

wowkaster
имхо цены из года в год все таки меняются и на следующий год прайс все равно править.
так зачем мучиться храня только день.месяц . Если случиться чудо и на новый сезон цены останутся фикс, перенос их один скл-запрос .
А хранение данных за предыдущие годы, полезно всегда, хотя бы для аналитики.

 

[antson]

винты сейчас большие, и как вариант можно хранить аж 365(6) строк на каждый тип размещения в отеле
выбрать sum(price) из allDaysReadyData where нужноеРазмещение и дата в диапазоне от и до
считать при индексах будет моментально.
а таблицу неспешно сгенериуешь раз в год.
для 10тысяч отелей и 10 вариантов заездов база будет весить меньше 10м