Discussion :

[Fred_ET]

Bon voila, je vous donne la situation.

J'ai une table comme cela:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CREATE TABLE Sessions(
	id_session	INTEGER CONSTRAINT sessionsIdSessionPrimKey PRIMARY          KEY,
	nom_session	CHAR(3) CONSTRAINT sessionsNomSessionUnique UNIQUE, 
	date_debut	DATE CONSTRAINT sessionsDateDebutNonNull NOT NULL,								
	date_fin	DATE CONSTRAINT sessionsDateFinNonNUll NOT NULL,				
	CONSTRAINT 	sessionsDateLogique CHECK(date_debut < date_fin)
);

Et je doit implémenter une contrainte (avec un TRIGGER BEFORE INSERT j'imagine) de facon a ce que deux sessions ne peuvent se chevaucher (en particulier, si une session se termine le 30/04, la session suivante ne peut commencer avant le 01/05). je dit un TRIGGER mais si c'est possible avec un CHECK c'est encore mieux... mais je ne crois pas qu'une fonction puisse vérifier sa aussi facilement.

Une session ne peut débuter un autre mois que janvier, mai ou septembre. (Le trigger pour cela est deja fait)

Je ne demande pas parceque je suis paresseux et que je veux la réponse facile... j'y ai pensé longtemps et je ne vois pas comment y arriver. J'ai deja fait toutes les autres contraintes qui seraient logiques dans ce cas donc oubliez tous le reste, c'est uniquement ce probleme que je n'ai pas résoud. En fait mon devor est terminé mis a part ce probleme.

Je vous remerci d'avance.

[coca25]

sur postgres on pourrait créer une règle qui donnerait à peu près:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
create rule regle_session as on insert to Sessions 
do instead
insert into Sessions
  select NEW.id_session, NEW.nom_session, NEW.date_debut, NEW.date_fin
   where NEW.date_fin not in (select NEW.date_fin from Sessions where NEW.date_fin between date_debut and date_fin)
       and NEW.date_debut not in (select NEW.date_debut from Sessions where NEW.date_debut between date_debut and date_fin)
;

ca peut te donner une piste

[Fred_ET]

hmm je suis pas sur de comprendre la logique dans cette requête. J'utilise Oracle en passant.

Je vais revoir ta requete mais si quequ'un sait comment faire avec oracle sa serait apprécié.

[pifor]

Une contrainte CHECK ne peut pas voir 2 lignes de la même table et ne peut donc être utilisée. Il faut bien utiliser un trigger en tenant compte du fait que la concurrence d'accès qu'offre Oracle nécessite de verrouiller la table (car si 2 transactions concurrentes peuvent insérer une ligne individuellement correcte mais les 2 lignes ensemble peuvent être incohérentes par rapport à la contrainte demandée).

Il y a une discussion (en anglais - avec un extrait du livre Expert Oracle) très intéressante pour un problème similaire ici: http://asktom.oracle.com/pls/ask/f?p...42171194352295

[sygale]

Oui je ferai aussi un trigger cependant je passerai les champs date_debut et date_fin en timestamp.
L'avantage est que tu devrais avoir presque aucun problème de cohérence/chevauchement de donnée.

Tu n'aurais pas de chance tout de même !

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
SQL> select systimestamp from dual;
 
SYSTIMESTAMP
------------------------------------------
21/11/06 13:45:14,012609 +01:00
 
SQL>

[remi4444]

C'est un problème pas très simple, je l'ai déja implémenté, voici le principe

- Un trigger before insert-update au niveau statement: qui locke la table (précaution à prendre suite à une très juste remarque de pifor! )
- Un trigger before insert-update au niveau ligne ("for each row") qui inscrit simplement une copie des rowid des lignes modifiées.
- Un trigger after insert-update au niveau statement qui effectue les controles de non chevauchement des lignes impactées dont les rowid sont stockés dans la table temporaire. En fonction du test, tu déclenche une exception ou pas (RAISE_APPLICATION_ERROR). Dans ce meme dernier trigger, tu efface tes lignes de ta table temporaire.

Tu es obligé de faire les tests dans ce dernier trigger car sinon tu aurais une erreur "table mutante"...

[nuke_y]

Ne faudrait-il pas gérer ce genre de conditions dans l'application plutôt que sur la table ?

[Fred_ET]

Merci pour votre aide. J'ai décidé de laisser faire cette contrainte car je n'avais plus le temps... Je crois comprendre comment faire maintenant mais je débordé donc je ne m'y attarderai pas maintenant. Parcontre, lorsque le professeur aura mis la réponse en ligne je la posterai pour ceux que sa intéresse.