Имеем модели Отель и Тип Номера. Связаны между собой соответственно связью one-to-many.
У Отеля есть поля-свойства, у Типа Номера есть поля-свойства, по которым осуществляется поиск.
И все бы ничего, только у Типа Номера есть такое свойство, как Цена. Цена не одна, а различная для разных периодов года:
16.09 - 31.05 4000 руб
1.06 - 5.09 5000 руб
и т.д.
Вопрос:
как организовать базу с этими Ценами, чтобы при этом можно было легко организовать поиск и по цене тоже?

забей на эту хуйню, пошел мартини допью один, мд5 сука свалил так и не допили )

ухахах! Та же проблема и у нас )))
Пока мы тупо решили хранить на каждый день свою цену )))

phpdude

забей на эту хуйню, пошел мартини допью один, мд5 сука свалил так и не допили )

а я так на тебя надеялся :D

mario

ухахах! Та же проблема и у нас )))
Пока мы тупо решили хранить на каждый день свою цену )))

т.е. модель дат, связанная с типом номера? за три дня мне тоже только это в голову пришло)))

мудаки вы :-)
 
заводишь цену стандартную на весь год прямо в таблице номера этого + таблицу "календарь" где есть диапазон - фром ту дейтс, прайс, и румайди.
 
ну и делаешь аля

phpdude

мудаки вы :-)
 
заводишь цену стандартную на весь год прямо в таблице номера этого + таблицу "календарь" где есть диапазон - фром ту дейтс, прайс, и румайди.
 
ну и делаешь аля

SQL

SELECT r.*, IFNULL(p.price, r.price) FROM rooms LEFT r JOIN price_calendar p ON r.roomid = r.id WHERE $date BETWEEN p.date_from AND p.date_to

а теперь прикрепи ко всему этому разные цены на размещения одного или двух человек.

mario, повыябывайся у меня еще :-)
 
и что сложного в этом? ну не один ко кногим, а многие ко многим.

phpdude

и что сложного в этом? ну не один ко кногим, а многие ко многим.

нет, номер дожен быть один, т.к. к нему еще привязаны сервисы и куча всякой херни )))
Еще например такая ситуация, назревает праздник, для части номеров делают отдельную цену, но у нас есть диапозон цен на даты... Да очевидно просто сделать еще одну таблицу, но при поиске будет дохуя вложенных запросов тогда...
В общем я думаю логичнее хранить на каждый день свою цену.

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

mario

Еще например такая ситуация, назревает праздник, для части номеров делают отдельную цену, но у нас есть диапозон цен на даты...

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

mario

а теперь прикрепи ко всему этому разные цены на размещения одного или двух человек.

ну обычно же у типа номера по стандартам конкретное количество человек.
чтобы стоимость различалась, если вместо двух человек один заедет в люкс, я не видел.
а св-во "дополнительное размещение 1, 2, 3 человек" можно хоть в сериализованное поле пихать, нахуй оно в поиске?
хотя, если в поиске есть поле "кол-во человек", то уже стоит задуматься...

Sinkler

хотя, если в поиске есть поле "кол-во человек", то уже стоит задуматься...

вот бля что с этим сделать надо придумать и я за дудов вариант)))

мудаки вы, выдумали слона, пошел подрочу

phpdude, ну ты вернешься?)

Sinkler

phpdude, ну ты вернешься?)

если инсульт не получу, если получу то только к пятнице вернусь, опять из больницы :-!

phpdude, тогда сначала придумай, а потом дрочи :D

я уже придумал же