Если хочется вообще любые сочетания, то можно дать возможность заводить расписания с любыми правилами и исключениями, сделать свой "конструктор" для них. К правилам (и исключениям) будут относиться: будни/выходные/праздники (придётся вести календарь праздников, в нём же учитывать все переносы), чётные/нечётные дни (по числу месяца из даты), дни недели, конкретные числа месяца, сами месяцы, аренда через равные промежутки времени и т.п. И для каждого расписания свои временные рамки, например, действует с 01/03/2011 по 31/06/2011.

Расписание 1:
- Правило 1: каждый 3-й день, начиная с 01/01/2011, с xx:xx по yy:yy

Расписание 2:
- Правило 1: каждый вторник, с aa:aa по bb:bb
- Исключение 1: кроме 15 числа

Расписание 3:
- Правило 1: по чётным, с 10:00 по 18:00
- Правило 2: по нечётным, с 8:00 по 13:00

Расписание 4 (извращенное):
- Правило 1: по чётным, если день недели = вт или чт, если не праздник и не выходной, с zz:zz по vv:vv
- Правило 2: по нечётным, если выходной, если вск, с mm:mm по nn:nn
- Исключение 1: кроме пятницы, кроме 13 числа
- Исключение 2: кроме 1 и 7 числа, кроме января
- Исключение 3: кроме чётных, кроме с ff:ff по gg:gg

У исключений приоритет выше, чем у правил, т.е. берем правила и вычитаем из них исключения — получаем нужные промежутки.

Возможно, придётся еще что-то для ночного времени придумывать, когда дата начала != дате окончания, а может и в эту схему ляжет...

WereWolf777Думаю использовать вариант с 3-мя таблицами для правил:
1. Расписание (ИД, Название)
2. Правило (ИД, ВремяНачала, ВремяОкончания, Столбцы с условиями). Столбцы с условиями: ТипДня(значения "Рабочие дни", "Выходные дни"), Четность ("Да", "Нет"), ДеньНедели, Число, Периодичность и т.д. с разрешением значения Null для столбцов с условиями.
3. Период_Правило (РасписаниеИД, ПравилоИД, ДатаНачала). ДатаНачала -- дата начала действия правила.

Аналогично с исключениями.Сам бы скорее сделал 3-ю таблицу не для правил/исключений, а для самих расписаний, с какого и по какое оно действует. И все правила и исключения действуют на всём протяжении расписания. Если же расписания все уникальны и не используются повторно, то возможно таблицы 1 и 3 совместил бы.

Но я не знаю вашу ситуацию, может вам надо именно так, как описали.
WereWolf777Ночное время вроде укладывается в эту схему и определяется условием ВремяНачала>ВремяОкончания, при этом вместо формулы ВремяОкончания-ВремяНачала будет использоваться (ВремяОкончания+1день-ВремяНачала).
Если нет ситуации, когда надо использовать формулу (ВремяОкончания + N дней – ВремяНачала), где N > 1, то может и сгодится.
WereWolf777Запрет на пересечение правил по принципу: любые 2 действующих правила по объекту аренды должны иметь хотя бы одно непересекающееся условие (несколько сумбурно, сорри).Это скорее запрет на вхождение одного правила в другое целиком, но тут тоже свои заморочки. Например, так:

Расписание N
- Правило 1: каждый чётный будний день, с 10:00 до 14:00
- Правило 2: каждый день с 12:00 до 13:00

Целиком 2-е в 1-е не входит, но проверка не всегда будет простая. Надо смотреть, что будет проще: проверять все наложения при вводе или корректно обрабатывать такие наложения правил при вычислениях.

WereWolf777Была идея условия вынести в отдельные таблицы, но по-моему это будет просто усложнением схемы.Опять же imho: я бы вынес некоторые вещи. Но для простоты можно попробовать сделать в одной. Решать вам.

WereWolf777Плюс история изменений.А без этого точно никак? Расписание менять будет не очень корректно, если только не выставлять для каждого правила и исключения своё время действия. Вариант: закрывать одно расписание и создавать новое, действующее с другого числа. Несколько расписаний можно привязывать к одному клиенту, договору и т.п.
WereWolf777З.Ы. Здесь редактировать сообщения можно? Не смог найти как.Можно. Надо стать модератором.

WereWolf777Дальнейшие размышления привели к следующей идее. Расписание -- это набор условий на конкретный период для конкретного объекта аренды.Т.е. чтобы получить для разных объектов одинаковые расписания (если это требуется), нужно будет заводить расписания, отличающиеся только объектами. Здась решать вам, предметная область вам должна быть знакома.
WereWolf777Наверное можно и вывести расписания отдельно, тогда получается, что при изменении/добавлении условий необходимо "закрывать" старое расписание и "открывать" новое. (так как присутствует желание хранения истории)А если вы просто меняете условия, то истории по определению не остаётся. Где-то нужно еще и даты изменений хранить... Поэтому здесь проще закрытие старого и создание нового расписания, чем десятки правил с разными периодами действия в одном расписании.
WereWolf777Я думаю, что подобную ситуацию можно переформулировать таким образом (разбить на несколько условий), когда не понадобиться использовать эту формулу.Можно, пожалуй. А можно добавить параметр "Кол-во дней от даты начала", и там вводить это N.
WereWolf777boottyЭто скорее запрет на вхождение одного правила в другое целиком, но тут тоже свои заморочки. Например, так:

Расписание N
- Правило 1: каждый чётный будний день, с 10:00 до 14:00
- Правило 2: каждый день с 12:00 до 13:00

Целиком 2-е в 1-е не входит, но проверка не всегда будет простая. Надо смотреть, что будет проще: проверять все наложения при вводе или корректно обрабатывать такие наложения правил при вычислениях.
Правило 2 не будет пропущено из-за пересечения с Правилом 1. С другой стороны возможен вариант -- использовать просто "сумму" правил, но тогда придется расчитывать итоговый период аренды для избежания двойного учета пересекающих диапазонов.
Еще к тому же можно придумать ситуацию, когда потребуется использовать исключения из исключений, исключения из исключений из исключений и т.д.Опять же, решать вам, что удобнее: контроль пересечений правил и исключений (t1_нач > t2_кон OR t2_нач > t1_кон) или вычисление суммы. Я бы пошёл вторым путём, наверное... Мне он алгоритмически более интересен.

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