Как сделать эффективный запрос по диапазону дат?

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

0LLEGator: Ну... а кто мешает второй столбец замутить? Да если и один, перебрать их программно гораздо легче, чем городить супер-пупер-сиквел-запросы, тем более, что не будет же у них 100 посетителей/секунда... А если будет, то здесь уже и кеширование понадобится и всё равно рабоатть быстрее будет по простой выборке (с кешированием конечно).

Алексей Черемисин: Ну на сколько я понимаю, эффективнее всё-таки городить запросы, чем перебирать данные программно, ибо БД заточена под выборку и обработку данных, тем более запрос-то не супер-пупер.

0LLEGator: Ну, не всегда так. Бывает, что чтобы отсортировать сотню записей (из нескольких миллионов) нужно так за ипачить запрос, что он не попадет в индексы, просрёт все кеши и будет по данным шуршать пол часа. Раньше выходили из этого положения созданием временных таблиц, но нонче это не особо модно, так как запросов таких может быть иной раз тышу в секунду. Так что я предпочитаю выдернуть поболее, в переделах разумного, и фильтрануть программно, когда это позволительно.
Да и не всегда можно запрос сделать, увы...

0LLEGator: Более того, база данных одна, а приложений может быть несколько, да на разных серверах. Так что чаще бывает просто выдернуть данные, их закешировать и обрабатывать. Но конечно же все зависит от данных, и прочих разных условий.

Алексей Черемисин: ну если у вас ничего не тормозит, то всё делаете правильно. Но по сути вопрос в поиске золотой середины.
А один запрос бывает не то что сложно написать - тормозить будет. Сделал процедурку, раздеил запросик и вуаля, зашуршало.

Олег: Ух... С высоты моего скромного опыта, хранимки и тригерры - зло неимоверное! Непереносимое, неконтролируемое, глючное, абсолютно не расширяемое, пережиток динозавров. По каждому пункту могу целую статью написать с примерами, почему так никогда, никогда не нужно делать.
Как пример - бизнес-система, программисты добавили немного данных в новые таблицы, привязали через вторичные ключи, залили новые данные по клиентам, а дурацкий триггер с этой вот самой хранимкой, ранее несколькими днями добавленный одним нехорошим человеком, взял и списал с нескольких тысяч клиентов малую денюжку. Откат базы данных и накат транзакций за услуги занял без малого тройку дней с кофем, матючком и куртизанками. Триггер просто вылидировал данные, но блокировал при этом отдельные поля и таблицы, а хранимка по откату пыталась вадидировать счет.
И это при том, что все было 10 раз проверено, оттестировано, отлажено и прочая прочая...
Не делайте так никогда. Тогда данные всегда будут правильные и пушистые, транзакции быстры и точны.

Олег: И да, иногда легче еще один сервер поставить с приложением, чем переносить базу на новый.. Ибо иногда это деньги и немалые за лицензии... Так что грузить лишний раз сервер баз данных не нужно, пусть себе работает, а резервный - отдыхает.

Вы не учли разрывы.

Ну тогда нужно добавить вычисляемый столбец, который бы считал количество найденных дней count(room), наример (в MS SQL count(*) НЕ игнорирует значения null) и сравнивать с количеством дней в диапазоне, ну и, конечно, группировать по номеру комнаты.

Зачем такие сложности? Лучше из таблицы занятых выбрать по не вхождению.

select roomid from roomsatus where roomid not in (select roomid from roomstatus where datefrom <= date and dateto >= date)

nApoBo3: Осталось только найти в условии (вопросе) таблицу занятых.А сложности - для их решения, размять часть мозга, ответственную за SQL.

Олег: Ну так и таблица свободных в вопросе не фигурирует. Есть только "владелец задал", каким именно образом не описано. ИМХО логично хранить вообще все даты, плюс столбец статуса, поскольку недоступность номера может быть по целому ряду причин. Так же можно хранить номер "документа", на основании которого проставлен статус( это может быть бронь ).