Je pense que les autres manquent la question... Ils pensent que votre table est peut-être déjà POPULÉE avec tous les week-ends et un statut d'ouverture ou non... Je suppose que votre table n'a un enregistrement que SI elle est réservée... vous devez donc trouver des enregistrements qui N'EXISTENT PAS DU TOUT... en vous basant sur une recherche automatique de dates...
Ceci est une modification d'un autre message que j'ai fait ici
Bien que je n'aie pas modifié le contexte de la requête, je n'ai mis que les colonnes associées à VOTRE table. Je comprends que vous ne vous opposez qu'à une seule table de salle et moi aussi (en fait). Cependant, pour comprendre l'alias "JustDates", cette INNER PRE-QUERY crée une table remplie dynamiquement de TOUTES LES DATES en effectuant une jointure cartésienne contre TOUTE autre table.. dans ce cas, votre table de réservations "Lieu" (je n'ai pas t voir votre référence de nom de table réelle explicitement, vous devrez donc changer cela). Donc, cela crée essentiellement une table de toutes les dates à partir de n'importe quel "aujourd'hui" et avance pendant 30 jours (via la limite), mais peut être de 40, 50, 300 ou autant que vous en avez besoin .. à condition que le "YourVenueTable" a au moins autant d'enregistrements que de jours que vous souhaitez tester. (même clarification dans le message dont elle est dérivée). Cet ensemble de résultats sortant 30, 40 ou n'importe quel nombre de jours est pré-filtré UNIQUEMENT pour le jour de la semaine donné de 1-Sunday ou 7-Saturday... Il devrait donc renvoyer un ensemble de résultats uniquement Apr 23, Apr 24, Apr 30, 1er mai, 7 mai, 8 mai, 14 mai, 15 mai, 21 mai, 28 mai, etc.
Donc MAINTENANT, vous avez un ensemble de résultats créé dynamiquement de tous les jours possibles où vous envisagez d'aller de l'avant. Maintenant, cela est joint à votre table de réservations de lieu réelle et est filtré pour renvoyer UNIQUEMENT les DATES où il n'est PAS trouvé pour l'id_venue qui vous intéresse. Dans votre exemple de données, il trouverait une correspondance les 23 et 24 avril et ne renverrait PAS ces enregistrements. Même chose avec le 30 avril... Cependant, il trouvera que le record de la liste de pré-qualification qui inclut le 1er mai ne trouvera PAS le match de date dans le tableau des lieux et inclura donc cela comme vous l'anticipez... Il continuera alors à sauter 7 et 8 mai, puis retour les 14, 15, 21, 28 mai, etc...
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
Remarque, et selon les autres publications de réservations, la requête pour les dates de disponibilité des dates de réservation faisant une limite de 30 ci-dessus peut être N'IMPORTE QUELLE table dans le système tant qu'elle a AU MOINS autant de jours que vous souhaitez attendre pour les réservations.. . Si vous voulez toutes les disponibilités pour une année à venir, vous voudriez 365 enregistrements dans la table utilisée pour un résultat cartésien pour obtenir le cycle @r à travers les enregistrements "date" créés dynamiquement.
