MySQL намира първия наличен уикенд

Мисля, че другите пропускат въпроса... Те смятат, че масата ви може вече да е НАСЕЛЕНА с всички уикенди и някакъв статус за отваряне или не... Предполагам, че вашата маса ИМА запис само АКО е запазена... по този начин трябва да намерите записи, които ИЗОБЩО НЕ СЪЩЕСТВУВАТ... въз основа на някакво автоматизирано търсене на дати...

Това е модификация на друга публикация, която направих тук

Въпреки че не промених контекста на заявката, поставих само колоните, свързани с ВАШАТА таблица. Разбирам, че се противопоставяте само на една маса, както и аз (всъщност). Въпреки това, за да разберем псевдонима „JustDates“, тази ВЪТРЕШНА ПРЕДВАРИТЕЛНА ЗАЯВКА създава динамично попълнена таблица с ВСИЧКИ ДАТИ чрез извършване на декартово присъединяване спрямо ВСЯКА КОЯ ДА СЕ друга таблица.. в този случай, вашата таблица с резервации „Место на провеждане“ (аз не не виждате изрично препратката към името на вашата действителна таблица, така че ще трябва да промените това). И така, това по същество създава таблица с всички дати, започващи от каквото и да е "днес" и продължава напред за 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 циклично чрез динамично създадени записи за "дата".