PHP|Débutant :: Forums

Saluton,
C'est parce que j'ai privilégié une solution sans sub-select (MySQL est peu performant avec les sub-select), sinon on doit pouvoir traiter le tout en jouant sur des sub-select dans des clauses WHERE NOT EXISTS, au prix d'une chute de performances par rapport à des jointures.

Je reste d'accord avec toi sur le principe, sauf quand l'approche relationnelle dénormalise la base dans le mauvais sens.
Un champ enum contrairement au champ SET ne peut avoir qu'une seule valeur à la fois de sa liste alors qu'un champ SET peut en être une combinaison. Lorsque la caractéristique du champ SET est conceptuellement fermée et non évolutive et doit être inclue en clé primaire, et si l'on considère un cas de figure où un champ set ne peut prendre que trois valeurs, on peut être amené à multiplier aisément par C(1,3)xC(2,3) enregistrements le poids des enregistrements correspondants en restant sur une approche relationnelle. J'ai déjà vu une telle approche générer sur une volumétrie minimaliste d'utilisation de l'application, écart de 1,000,000 d'enregistrements pour une base de 360,000 enregistrements avec un champ SET. Et les projections de montée en charge faisaient vraiment peur. Dans ce cas en plus les requêtes de productions restaient simples.
Dans mon cas ici, ce choix a été murement réfléchi et reste normalisé au sens du cahier des charges et en considérant le reste de la structure, car on n'aura jamais à requêter sur l'ensemble des données mais que sur l'établissement (etbid) concerné, et si on a 16 enregistrements par établissement cela sera le max. Vu le nombre d'enregistrements, utiliser une sous-requête n'aura pas d'impact sur les performances.
Tes arguments dans l'ensemble ne m'ont pas convaincu.

Dernière modification par Jc (24-07-2011 10:47:39)

Comme tu le dis si bien, "la plupart du temps".
Mais comme l'objet de ma réfléxion portait sur les aspects particuliers, je vais opposer ton hérésie relationnelle à l'hérésie conceptuelle. En effet Si la colonne SET existe c'est notamment pour éviter qu'une entité unique soit représentée par deux ou plusieurs enregistrements en base de données, ce qui, lorsque cela arrive, va à l'encontre de la notion même de clé Primaire et j'en passe. Pour peu que les relations de cette table soient sur un plan relationnel assez complexe, cela devient purement ingérable à tous les niveaux.

Ensuite un champ SET est géré au niveau BIT par MySQL, ce qui reste beaucoup plus rapide que d'autres.

A utiliser avec modération donc et lorsque cela reste nécessaire.

Dernière modification par Jc (24-07-2011 12:59:13)

Je comprends bien.
Parfois cependant, il arrive un moment, où la difficulté n'est pas "contournable" et on ne peut pas parfois changer la définition d'un objet du cahier des charges juste pour éviter les prises de tête.
Je reste convaincu que la requête finale pour revenir à l'objet de mon post, restera relativement simple, dès que j'ai un peu de temps pour revenir dessus (il le faudra de toute façon) je m'y colle et je posterai la solution retenue.

Merci MK

Je refais la table de vérité car on est sur un champ SET et à ce titre, 'midi,soir' est différent de 'midi','soir' et il n'en est pas tenu compte.

Voilà donc

Ce tableau recense toutes les valeurs possibles des colonnes. Ecrit différemment donc, les valeurs possibles de t.nbsj sont 'midi','soir' lorsque def.opt=false et def.nbsj='midi,soir'.

++

Dernière modification par Jc (29-07-2011 19:13:07)

Pour rester constructif je pense avoir trouvé cette solution globale

Mais tu avoueras que cela relève vraiment de la capilotraction.

Si tu acceptes un retour tabulaire on peut modifier la requête comme ceci

Bonjour,

Donc comme convenu je reviens vers vous pour partager avec vous la solution que j'ai retenue.
Un grand Merci à MK, car j'avoue que j'avais un peu oublié "l'effet NULL" sur les jointures lorsqu'il n'y a pas d'enregistrement sur la jointure, et c'est la méthode que j'ai choisie car comme je l'ai expliqué précedemment, je me devais d'exclure les requêtes union et celles qui utilisent la forme "not in", pour finalement passer par les requêtes dérivées.
Donc après un petit effort de transposition de la requête de production pour vous voici ce que cela donne :

Comme je m'en doutait, elle est très simple et couvre l'ensemble des cas de figure présenté dans le tableau précédent.

Merci à vous,

Cordialement,

Jc

Dernière modification par Jc (06-08-2011 08:14:12)