-
Edité par Fred2000Fred2000 7 juillet 2019 à 13:48:27

Et si tu généralises la notion de séance en y intégrant les périodes de révision, en transformant ta table SEANCE en CALENDRIER, avec une table TYPE_PLAGE (cours ou révision ou n'importe quoi d'autre) ?

Il faut aussi que tu définisses les plages horaires quelque part parce que dans ton modèle, rien n'empêche un candidat ou un formateur de choisir les horaires qu'il veut (y compris la nuit) ou de faire des révisions à n'importe que moment (y compris le dimanche quand le concessionnaire est fermé). Le risque de chevauchement et de non-concordance est important. Même si tu utilises le type INTERVAL, la gestion du temps risque d'être compliquée.

K

Bonjour,

Dans un premier temps, les règles de gestion temporelles évoquées par Kudbuloken peuvent être gérées de manière applicative, pour faciliter la modélisation. Selon moi le modèle en place est suffisant, même si c'est vrai que la gestion des horaires (créneaux) serait un plus non négligeable ...

Concernant ta question, lorsque l'utilisateur de l'application crée (ou modifie) une séance, il faut rechercher les motos et les formateurs disponibles sur la plage, et en cas de modification avertir l'utilisateur d'un éventuel conflit ...

Pour cela, pas besoin d'une entité disponible, une requête sera suffisante :

-- Motos disponibles sur un créneau donné
SELECT M.*
FROM
	Moto M
		LEFT JOIN Révision R
			ON M.id = R.id_moto
			AND R.heure_debut =< 'heure de fin séance'
			AND R.heure_fin >= 'heure de début séance'
WHERE R.id_moto IS NULL;

-- Formateurs disponibles sur un créneau donné
SELECT F.*
FROM
	Formateur F
		LEFT JOIN Séance S
			ON F.id = S.id_formateur
			AND S.heure_debut =< 'heure de fin séance'
			AND S.heure_fin >= 'heure de début séance'
WHERE S.id_formateur IS NULL;

Bonsoir,

Oui, normalement mon analyse est assez correct.

Merci beaucoup pour votre aide, je vais me concentrer sur les requêtes.