Я думаю, что другие упускают вопрос ... Они думают, что ваша таблица уже НАСЕЛЕНА со всеми выходными и некоторым статусом, открывать или нет ... Я предполагаю, что ваша таблица имеет только запись, ЕСЛИ она зарезервирована ... таким образом, вам нужно найти записи, которые вообще НЕ СУЩЕСТВУЮТ ... на основе некоторого автоматического поиска дат ...
Это модификация другого поста, который я сделал здесь
Хотя я не изменил контекст запроса, я только вставил столбцы, связанные с ВАШЕЙ таблицей. Я понимаю, что вы идете против одного столика, и я тоже (на самом деле). Однако, чтобы понять псевдоним «JustDates», этот INNER PRE-QUERY создает динамически заполняемую таблицу ВСЕХ ДАТ, выполняя декартово объединение против ЛЮБОЙ другой таблицы .. в данном случае, ваша таблица резервирований «Место действия» (я не Я не вижу вашей реальной таблицы имен в явном виде, так что вам придется изменить это). Таким образом, это, по сути, создает таблицу всех дат, начиная с того, что есть «сегодня», и продвигается на 30 дней (через лимит), но может быть 40, 50, 300 или столько, сколько вам нужно… при условии «YourVenueTable» имеет как минимум столько записей, сколько дней вы хотите проверить. (то же самое разъяснение в посте, это было получено из). Этот набор результатов, выходящий за 30, 40 или сколько угодно дней, предварительно фильтруется ТОЛЬКО для данного дня недели 1-воскресенье или 7-суббота ... Таким образом, он должен возвращать набор результатов только 23 апреля, 24 апреля, апреля 30 мая, 1 мая, 7 мая, 8 мая, 14 мая, 15 мая, 21 мая, 28 мая и т. Д.
Итак, сейчас у вас есть динамически созданный набор результатов всех возможных дней, которые вы планируете двигаться вперед. Теперь это присоединяется к вашей фактической таблице бронирования мест и фильтруется, чтобы ТОЛЬКО возвращать те ДАТЫ, когда они НЕ найдены для id_venue, который вас беспокоит. В вашем примере данных он БУДЕТ найти совпадение 23 и 24 апреля и НЕ вернет эти записи. То же самое с 30 апреля ... Однако, он обнаружит, что запись в списке предварительного отбора, который включает 1 мая, НЕ найдет совпадение даты в таблице места и, следовательно, включит его, как вы ожидаете ... Затем он будет продолжать пропускать 7 и 8 мая, затем возвращение 14, 15, 21, 28 и т. Д. ...
select JustDates.OpenDate
from
( select
@r:= date_add( @r, interval 1 day ) OpenDate
from
( select @r := current_date() ) vars,
Venue
LIMIT 30 ) JustDates
where
DAYOFWEEK( JustDates.OpenDate ) IN ( 1, 7 )
AND JustDates.OpenDate NOT IN
( select Venue.date
from Venue
where Venue.id_venue = IDYouAreInterestedIn
and Venue.Date = JustDates.OpenDate )
order by
JustDates.OpenDate
Обратите внимание, и для других проводок резервирования запрос на даты доступности даты резервирования с ограничением 30 выше может быть ЛЮБОЙ таблицей в системе, если в ней по крайней мере столько дней, сколько вы ожидаете резервирование ... Если вы хотите, чтобы в следующем году была доступна вся доступность, вы бы хотели, чтобы 365 записей в таблице, используемой для декартового результата, позволяли @r циклически перемещаться по динамически создаваемым записям "date".