Есть задача сделать для сети отелей поиск свободного номера по дате.

Соответственно как вообще хранить статус номера в БД? У номера может быть 3 состояния, 1 - занят, 2 - свободен, 3 - промежуточное.

Дней в году 365.
Делать 365 колонок в таблице o_O ? И при поиске например свободного номера на 3 месяца составлять запрос по 90 колонкам?

Есть наверное более простое решение!?

Модератор: Тема перенесена из форума "Microsoft SQL Server".

GloryХранить периоды, а не дни

В смысле сделать 12 таблиц по 30 дней?

MasterZiv
Блин, чё там 365 колонок ? Это ж каждый дурак сделает.

Делай 365 таблиц (366, если быть точным).

О, точно спасибо, так и сделаю. Как я сам-то не подумал.

GloryКакие еще 12 таблиц ?
Одна единственная таблица
"ИД номера", "Статус", "Начало периода", "Конец периода"

Ну допустим у меня 100 различных номеров в сети отелей на 100 гостиниц.
И к примеру:
01.05 - статус номера 1 (занят)
02.05 - статус 3 (выселяется)
03.05 - статус 2 (свободен)
04.05 - статус 1 (занят)
и т.д.

Т.е. статус номера может каждый день меняться, как тут статус к периоду привязать?

GlorysoftrixТ.е. статус номера может каждый день меняться, как тут статус к периоду привязать?
"ИД номера", "Статус", "Начало периода", "Конец периода"

Glory, Вы бы не могли чуть подробнее написать. Что Вы подразумеваете под периодами.
К примеру:
Начало периода: 01.05
Конец периода: 02.05
Если так, то получаем 365 строк в таблице на каждый номер? И как по ним поиск делать на конкретные даты?

Dimitry SibiryakovС периодами запросы будут монструозны. Я бы не парился и делал один день - одна запись.
Запросы вырождаются в простой not exists (... between...).


Т.е. Если я правильно понял Вы предлагаете таблицу вида

id status_id date

И соответственно записывать только свободные даты. А поиск делать вида
Select * from table where status_id=1 and date beetwen 01.05.2012 and 25.05.2012

Только если у нас 3000 номеров, то объем таблицы может вырасти до 1 миллиона записей. Или это норм?

GloryА вы что на год вперед знаете, когда номер заселен/освобжден что ли ?


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

MasterZivТогда эти записи нужно будет каждый день генерировать.


Может для каждого номера, сразу генерировать 365 строк, а затем только Update делать?

Ага, ну вроде со структурой таблицы понятно.

id room_id status date

А, как по ней поиск cделать?

Если добавлять в таблицу только забронированные даты то поиск может выглядеть как-то так:

SELECT * FROM `rooms` as r WHERE r.id not in (select s.room_id from shedule as s where s.status=2 or s.status=3 beetwen 01.05.2012 and 25.05.2012 group by room_id)

Похоже на правду?

GloryТ.е. хранить 365 записей на номер - это нормально ? А 730 - уже ненормально ?
А если номер не будет ни разу заселен в течении года ?

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

GloryЭти 365 строк только будут место занимать.
Все информация из них умещается в одну запись
"2", "01.01.2012", "31.12.2012"
или вообще
"2", "01.01.2012", "31.12.9999"

Это так, но при условии, что в любой момент времени забронирован весь год. Тогда и данные хранить смысла нет. :)
А, по факту будет примерно так:
На сегодняшний день забронировано:
"2", "01.01.2012", "02.01.2012"
"2", "03.01.2012", "05.01.2012"
"2", "06.01.2012", "08.01.2012"
"2", "21.01.2012", "22.01.2012"
На завтра, часть дат с брони снято.
На после завтра, часть дат перебронированны на новые.
и т.п.

Dimitry Sibiryakov,
Ну в принципе, да или можно их в архив скидывать в конце года, чтобы таблицу не растить.