Vous n'êtes pas identifié(e).
Bonjour,
Besoin d'un petit coup de main sur une requête, peut-être que d'ici demain j'aurais trouvé, mais en attendant ca m'agace un peu...
Donc voici mon souci.
Je pars de deux tables.
- La première, appelons-là "def" pour définition est une table à clé primaire composite (normalisée je précise) à trois champs : etbid (INT unsigned not null), gsid (TINYINT unsigned not null) et nbsj (SET 'midi','soir')
- La seconde est une table classique (appelons-là "travail") avec un id (INT unsigned not null auto_increment) en clé primaire, et avec les champs etbid,gsid et nbsj (les mêmes que ci-dessus) indexés.
Comme vous le savez déjà, le champ SET défini en 'midi','soir' peut prendre les valeurs suivantes : 'midi', 'soir' et 'midi,soir'.
Mon besoin est de trouver la requête qui me liste les travaux restant de disponible par rapport à leur définitions (table def). En sachant que je travaille sur etbid=x, la liste doit donc retourner l'ensemble des travaux disponibles en fonction de gsid et de nbsj.
Ex: voici une def : etbid=1, gsid=3, nbsj='midi,soir' et voici le seul travail réalisé : etbid=1, gsid=3, nbsj='soir' . Dans ce cas la requête doit retourner etbid=1, gsid=3, nbsj='midi'.
Si vous avez des questions, n'hésitez pas.
Dernière modification par Jc (18-07-2011 17:53:31)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
oup's, j'comprend rien
a++
Hors ligne
nan, une affirmation :D
a++
Hors ligne
En gros, il me faut une requête qui liste l'ensemble des travaux définis moins ceux déjà réalisés.
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
je ne comprend pas "etbid", "gsid" et "nbsj".
pour moi çà, c'est du schpoun's
a++
Hors ligne
Ce sont les noms des champs. Considère id_1, id_2, et id_3 à la place si cela te fait plaisir
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Jc, tu connais ma devise ?
a++
Hors ligne
Oups... j'ai oublié de préciser une chose.
Il faut rajouter une option dans la table de définition. Appelons-là opt. elle est définie en (true/false). Quand l'option est "true" et nbsj dans la même table (table def) est 'midi,soir' la valeur de nbsj dans la table travail ne peut être que 'midi,soir' également, sinon (si opt est "false") la valeur de nbsj dans la table travail peut-être soit 'midi' soit 'soir'.
Voilà,
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Saluton,
JC, je crains, qu'enfermé dans ta problématique, ta vision des choses n'embarque trop d'implicite pour nous la rendre compréhensible.
Ainsi, tout bêtement, comment distingue-t-on, dans tes tables, un travail "réalisé" d'un travail "à réaliser".
Même après plusieurs lectures des informations que tu nous fournis, cela ne m'apparaît pas clairement. Et ceci est un euphémisme.:/
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Merci MK pour ta réponse.
En fait il ne s'agit pas d'un travail et on s'en fou, c'etait juste pour le rendre "plus concret". Par contre la table définition en est bien une. Elle est là pour donner le cahier des charges des enregistrements qu'il est possible de créer dans l'autre.
Bien que j'ai beaucoup avancé sur cette problématique, j'en suis arrivé à la conclusion que lapalisse aurait pu formuler mieux que moi d'ailleurs, c'est que le SGBDR ne peut retourner des enregistrements qui ne sont pas encore crées, bien que l'information recherchée soit disponible. Comme quoi parfois, connaître une évidence, n'aide pas à en prendre conscience pleinement.
Je reformule donc: Si dans ma table def j'ai : etbid=1, gsid=3,nbsj='midi,soir',opt=false (les autres cas sont bateau à résoudre), et que dans l'autre table 'appelons la x' j'ai pour etbid=1 et gsid=3 un seul enregistrement avec nbsj='midi', ma requête doit me dire que l'enregistrement etb=1,gs=3 et nbsj='soir' reste de disponible pour créer l'enregistrement correspondant dans la table x.
Pour les curieux, comme je l'ai dit précedemment, si opt=true et que nbsj='midi,soir', dans l'autre table il ne sera possible que de créer le même enregistrement c'est à dire etbid=1,gsid=3 et nbsj='midi,soir'.
Le gros du problème c'est de réaliser une exclusion sur un champ set : avec 'midi,soir' - 'midi' = 'soir'. Peut être d'ailleurs la solution réside à travailler le champ SET au niveau BIT avec un NAND... et de sortir les résultats dans une table de type MEMORY.
J'ai pensé résoudre le problème avec une requête union, mais c'est à oublier car quand la requête d'exclusion dans une clause where est une requête union, la table d'origine doit elle aussi avoir le même nombre de champs que dans la requête d'exclusion ce qui me la fait exclure d'office car la requête de base doit absolument comporter d'autres champs, et l'exclusion ne porte que sur la valeur d'un seul en particulier.
++
Dernière modification par Jc (23-07-2011 13:51:00)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Je reformule donc: Si dans ma table def j'ai : etbid=1, gsid=3,nbsj='midi,soir',opt=false (les autres cas sont bateau à résoudre), et que dans l'autre table 'appelons la x' j'ai pour etbid=1 et gsid=3 un seul enregistrement avec nbsj='midi', ma requête doit me dire que l'enregistrement etb=1,gs=3 et nbsj='soir' reste de disponible pour créer l'enregistrement correspondant dans la table x.
Encore besoin d'une précision, qu'est-ce qui doit être UNIQUE dans la table x, le couple etbid et gsid ou le trio etbid, gsid et nbsj (lequel, en outre doit être égal à 'soir' ) ?
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Appliquons la formule : P = π . D
Nous savons que π = 3,14 et que D = 2m
donc P = 3,14 x 2 = 6,28m
Exemple :
b² se lit "b au carré", cela équivaut à b.b
b² = b x b = b.b "b au carré égale b que multiplie b"
Autres exemples
2² = 4 3² = 9 5² = 25
"racine carrée de six plus trois égale racine carrée de neuf égale trois"
Sœil = π.32 = 3,14 . 9 = 28,3mm2
Stel = π.2002 = 3,14 . 40 000 = 125 600mm2
e ^ (i x π) = -1
e[puissance](i x π)[/puissance] = -1
ayé, j'ai ma solution
a++
Hors ligne
La réponse est ici
Je pars de deux tables.
- La première, appelons-là "def" pour définition est une table à clé primaire composite (normalisée je précise) à trois champs : etbid (INT unsigned not null), gsid (TINYINT unsigned not null) et nbsj (SET 'midi','soir') EDIT: opt (BOOL) qui ne fait pas partie de la clé primaire.
- La seconde est une table classique (appelons-là "travail") avec un id (INT unsigned not null auto_increment) en clé primaire, et avec les champs etbid,gsid et nbsj (les mêmes que ci-dessus) indexés.
En sachant que la seconde table contient les éléments déjà crées en fonction donc de etbid, gsid, et nbsj.
Dernière modification par Jc (23-07-2011 16:12:37)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
mais je suis sérieux moaaaaaaaaaa
a++
Hors ligne
La réponse est ici
Jc a écrit :Je pars de deux tables.
- La première, appelons-là "def" pour définition est une table à clé primaire composite (normalisée je précise) à trois champs : etbid (INT unsigned not null), gsid (TINYINT unsigned not null) et nbsj (SET 'midi','soir') EDIT: opt (BOOL) qui ne fait pas partie de la clé primaire.
- La seconde est une table classique (appelons-là "travail") avec un id (INT unsigned not null auto_increment) en clé primaire, et avec les champs etbid,gsid et nbsj (les mêmes que ci-dessus) indexés.En sachant que la seconde table contient les éléments déjà crées en fonction donc de etbid, gsid, et nbsj.
Désolé, mais je ne comprends pas en quoi cela répond à ma question mon bon JC.
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Pour l'instant je comprends que tu cherches à faire ça, mais je me doute qu'il s'agit d'autre chose
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
C'est ça^^
Je vais me baser sur ta requête. pour d.etbid=t.etbid et d.gsid=t.gsid, si la table d à un enregistrement où nbsj='midi,soir' et que la table t à un enregistrement où nbsj='midi', il faut que la requête retourne un enregistrement où nbsj='soir'. Très simple en apparence car comme je l'ai dit précédemment la table def ne contient pas d'enregistrement dans ce contexte avec nbsj='soir' mais 'midi,soir' ...
EDIT: "c'est ça = c'est ça, il s'agit d'autre chose"
Dernière modification par Jc (23-07-2011 18:52:56)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Comme ça alors ?
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Non MK.
1) etbid, gsid, nbsj ne peuvent être null à un moment donné (ils sont tous défini comme NOT NULL d'ailleurs).
2) voici les valeurs possibles pour nbsj dans t
a) 'midi,soir' (si opt=true et d.nbsj='midi,soir')
b) 'midi' ou 'soir' si d.nbsj='midi,soir' et opt=false
c) 'midi' quand d.nbsj='midi'
d) 'soir' quand d.nbsj='soir'
Ce que je n'ai pas encore trouvé c'est comment gérer correctement le cas b) dans ma requête. Actuellement ma meilleure réponse si t.nbsj='midi' par exemple ma requête me retourne 'midi,soir'. Ce qui est juste dans l'absolu car non présent dans t.nbsj et défini dans d.nbsj, or il doit me retourner dans ce cas, 'soir'....
Dernière modification par Jc (24-07-2011 05:45:47)
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne
Non MK.
1) etbid, gsid, nbsj ne peuvent être null à un moment donné (ils sont tous défini comme NOT NULL d'ailleurs)..
Dans une jointure LEFT JOIN, quand la jointure n'opère pas, les colonnes de la table sans correspondance avec la clause ON sont remplacées par NULL.
2) voici les valeurs possibles pour nbsj dans t
a) 'midi,soir' (si opt=true et d.nbsj='midi,soir')
b) 'midi' ou 'soir' si d.nbsj='midi,soir' et opt=false
c) 'midi' quand d.nbsj='midi'
d) 'soir' quand d.nbsj='soir'Ce que je n'ai pas encore trouvé c'est comment gérer correctement le cas b) dans ma requête. Actuellement ma meilleure réponse si t.nbsj='midi' par exemple ma requête me retourne 'midi,soir'. Ce qui est juste dans l'absolu car non présent dans t.nbsj et défini dans d.nbsj, or il doit me retourner dans ce cas, 'soir'....
Tout ceci me laisse à penser, mais je manque d'éléments pour l'affirmer, qu'il y aurait comme un défaut de modélisation et, partant, de conception dans cette partie de la base de données.
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
Bon en synthétisant les informations que tu nous a fourni j'en arrive à cette version de la requête
Dont je t'explique la logique.
Je mets en jointure interne (INNER JOIN) les deux tables en m'assurant qu'il existe une ligne dans t pour laquelle t.nbsj contient 'midi'.
Je mets ensuite en jointure externe (LEFT OUTER JOIN) avec une deuxième occurrence de la table travail, aliassée en tt, et pour laquelle je m'assure qu'il existe une valeur 'soir' dans tt.nbsj.
Dans le filtre WHERE, je vérifie que d.opt est à false, que d.gsid est à 'midi.soir' et que je n'ai pas trouvé de ligne dans tt où tt.nbsj contienne 'soir', donc qui me renvoie une ligne avec NULL pour n'importe quelle colonne de tt.
Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy
Hors ligne
J'avoue que tu es étonnant MK.
Bien que ta requête m'offre la moitié de la solution. En effet, si j'ai déjà une requête qui me traite de tous les cas sauf celui-ci, ta requête ne traite que ce cas particulier, fonctionne, mais à moitié car elle ne traite le cas que si 'midi' est défini dans t pas si c'est 'soir', et dans ce cas, il faut refaire la requête en inversant les conditions comme suit:
Dans tous les cas, j'ai une nouvelle approche grâce à toi et je vais voir comment je peux l'intégrer dans ma requête globale.
POO PHP+Ajax en MVC avec PDO et Bases de données épaisses : What else?
Hors ligne