Jeg tror, de andre mangler spørgsmålet... De tror, at dit bord måske allerede er BEFOLKET med alle weekender og en eller anden status om åbent eller ej... Mit gæt er, at dit bord kun HAR en rekord, HVIS det er reserveret... derfor skal du finde poster, der SLET IKKE EKSISTERER... baseret på nogle automatiske Søg efter datoer...
Dette er en ændring af et andet indlæg, jeg har lavet her
Selvom jeg ikke ændrede konteksten for forespørgslen, indsatte jeg kun de kolonner, der er knyttet til DIN tabel. Jeg forstår, at du kun går imod et enkelt spillested, og det er jeg også (faktisk). For at forstå "JustDates"-aliaset opretter denne INDRE FORFORSPØRGSEL en dynamisk udfyldt tabel med ALLE DATOER ved at lave en kartesisk joinforbindelse mod ENHVER anden tabel. i dette tilfælde, din "Venue"-tabel med reservationer (det gjorde jeg' ikke se din faktiske tabelnavnreference eksplicit, så du bliver nødt til at ændre det). Så dette skaber i det væsentlige en tabel over alle datoer, der starter fra hvad "i dag" er og går fremad i 30 dage (via grænse), men kan være 40, 50, 300 eller så mange, som du har brug for. forudsat "YourVenueTable" har mindst lige så mange rekorder som dage, du vil teste for. (samme præcisering i indlæg som dette blev afledt af). Dette resultatsæt, der går ud 30, 40 eller hvor mange dage der end er, er KUN forudfiltreret for den givne ugedag 1-søndag eller 7-lørdag... Så det skulle returnere et resultatsæt på kun 23. apr., 24. apr. 30, 1. maj, 7. maj, 8. maj, 14. maj, 15. maj, 21. maj, 28. maj osv.
Så NU har du et dynamisk skabt resultatsæt af alle mulige dage, du overvejer at komme videre. Nu bliver det føjet til din faktiske mødestedsreservationstabel og filtreret til KUN at returnere de DATOER, hvor det IKKE findes for det id_venue, du er bekymret for. I dit dataeksempel VILLE den finde et match den 23. og 24. april og IKKE returnere disse poster. Samme med 30. apr... Den VIL dog konstatere, at rekorden i prækvalifikationslisten, der omfatter 1. maj, IKKE vil finde datomatchen i spillestedstabellen og dermed inkludere det, som du forventer... Det vil så fortsætte med at springe over 7. og 8. maj, så retur 14., 15., 21., 28. maj osv...
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
Bemærk, og i henhold til de andre reservationsposter, kan forespørgslen om reservationsdatoens tilgængelighedsdatoer med en grænse på 30 ovenfor være ENHVER bord i systemet, så længe det har MINDST så mange dage ude, som du vil se frem til reservationer. . Hvis du vil have al tilgængelighed for et kommende år, vil du have 365 poster i tabellen brugt til et kartesisk resultat for at få @r til at cykle gennem dynamisk oprettede "dato"-poster.