Discussion :

[RPGamer]

Salut les développeurs pros !

Je suis développeur amateur et je cherche a faire une requête assez étrange mais somme toute évidente et je ne suis pas parvenu à trouver la syntaxe adaptée.

J'ai une table contenant un champ avec une valeur entière. J'aimerais sélectionner des entrées de cette table tant que la somme des valeurs de ce champs est inférieure ou égale à une valeur fixe (par exemple 8). Je fais cette requête en imposant une clause ORDER BY mais l'ordre n'a pas d'importance pour le fond de la requête.

Par exemple si la table contient des entrées avec comme valeurs de ce champs :

3
4
6
2

La requête retournera les 3 première entrées pour une valeur fixe de 8 puisque 3 + 4 < 8 mais 3 + 4 + 6 > 8. Pour une autre table avec ces valeurs :

1
2
2
1
2

La requête retournera toutes les entrées, 1 + 2 + 2 + 1 + 2 = 8.

Plus précisément, je souhaite que cette somme soit de minimum 8 (sorte de do ... while). La valeur du champs allant rarement au-dessus de 10.

J'ai pensé à utiliser SUM() dans la clause WHERE, mais la clause WHERE ne semble pas adaptée pour un comportement "tant que".

Voilà, si vous avez une idée, c'est avec joie

Salutations et bon week-end

[CinePhil]

Quel besoin étrange !

Par exemple si la table contient des entrées avec comme valeurs de ce champs :

3
4
6
2

La requête retournera les 3 première entrées pour une valeur fixe de 8 puisque 3 + 4 < 8

Comme il n'y a a priori pas d'ordre dans une table SQL, il faudrait aussi que la requête retourne 3 + 2 et 4 + 2 qui sont aussi des couples inférieurs à 8

Je crains que ce que tu demandes ne soit pas possible simplement en SQL, surtout avec MySQL qui ne connait pas les fonctions récursives.

Au passage, les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de lignes et de colonnes.

[RPGamer]

OK, il existe une alternative, je vais la mettre en place.

J'accorde que ce besoin est étrange. En réalité, j'ai un champ contenant des données sérialisées et un autre le nombre des donnés sérialisées stockées. Une entrée est jointe à une autre entrée d'une autre table pour obtenir d'avantage d'informations. Ceci m'évite d'avoir une table qui grossi 10 fois plus vite que l'autre (alternative) et deux table prend du sens pour les informations concernées (et encore plus si je dois mettre en place mon alternative). De plus c'est beaucoup plus convivial à traiter ensuite avec PHP.

J'aimerais limiter le nombre de données sérialisées récupérées et donc je cherche à limiter la taille du résultat par une requête de ce type. Les entrées étant stockées sur une longue période (archivage).

J'ai souvent entendu le mot "champs" pour parler précisément des colonnes en MySQL, y compris dans la doc.

[SQLpro]

Cette requête serait d'une grande simplicité si MySQL savait faire du SQL... Mais il est loin d'implémenter un SQL digne de ce nom.

Par exemple cela serait simple avec les fonctions de fenêtrage car on peut faire une SOMME fenêtrée et s'arrêter à la ligne que l'on souhaite...
Lisez l'article que j'ai écrit sur le sujet : http://sqlpro.developpez.com/article...clause-window/
Manque de Pot, MySQL n'implémente pas ce genre de fonctions !!! Alors que tous les autres SGBDR le font....

Cela serait aussi simple si MySQL acceptait la récursivité... Dans ce cas on peut additionner ligne par ligne et s'arrêter dès que...
Lisez l'article que j'ai écrit sur le sujet : http://sqlpro.developpez.com/cours/s...te-recursives/
Re manque de Pot, MySQL n'implémente pas ce type de requêtes !!! Alors que tous les autres SGBDR le font....

Tout cela a été normalisé il y a dix ans...

Mais il est vrai que MySQL est loin d'être un véritable SGBDR... Tout juste un gestionnaire de fichier avec un vernis SQL !

A lire sur le sujet : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

Alors si vous voulez faire cela, utilisez un véritable SGBDR comme PostGreSQL, qui possède lui, l'avantage d'être réellement gratuit !

A +

[CinePhil]

J'accorde que ce besoin est étrange. En réalité, j'ai un champ contenant des données sérialisées et un autre le nombre des donnés sérialisées stockées.

Euh... tu veux dire que tu as par exemple dans une ligne ceci ?
serialisation / nb_serialise
1, 3, 5 / 3

Si c'est ça, c'est que ta BDD est mal modélisée. La première règle d'or en matière de base de données : 1 colonne = 1 donnée.

Et bis repetita :

Au passage, les champs sont à la campagne ou dans les formulaires, pas dans les tables SQL qui ne sont composées que de lignes et de colonnes.

Une entrée est jointe à une autre entrée d'une autre table pour obtenir d'avantage d'informations.

Ça s'appelle une clé étrangère et on rassemble les informations des deux tables à l'aide de jointures.

Ceci m'évite d'avoir une table qui grossi 10 fois plus vite que l'autre

C'est surtout le fruit d'une bonne modélisation des données... quand on modélise correctement !

J'aimerais limiter le nombre de données sérialisées récupérées

Non. Il faut récupérer les données nécessaires, éventuellement en en limitant le nombre à l'aide de la clause LIMIT de MySQL puis éventuellement sérialiser le jeu de résultats obtenu dans le programme PHP, par exemple pour le passer à un programme Javascript.

et donc je cherche à limiter la taille du résultat par une requête de ce type.

Voir clause LIMIT de MySQL.

J'ai souvent entendu le mot "champs" pour parler précisément des colonnes en MySQL, y compris dans la doc.

C'est une mauvaise habitude que l'on trouve hélas même dans la doc de MySQL.
Cependant, comment ajoutes-tu un "champ" à une table en SQL ?

Code :

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

1
2
ALTER TABLE la_table
ADD COLUMN la_colonne le_type les_contraintes

CQFD !

Au fait, on ne dit pas non plus "entrées" mais "lignes" !

[RPGamer]

Je connaissais et je connais toujours ces principes de base. Mais j'ai fait le pour et le contre avec d'autres argument pratiques. Je fais effectivement une jointure avec une clé étrangère. Si je me limite à une donnée = une colonne, je peux avoir une ligne dans une table et 10 lignes dans une autre, et peut être que 2 pour une autre requête, bref, un truc pas très clair en définitive. C'est plus trivial dans mon cas au niveau du jeu de résultats. Ce qui m'avait motivé c'est ça (une ligne dans une table <=> une ligne dans une autre), ce qui rend la jointure simple et le nombre de lignes d'une table par rapport à l'autre raisonnable. En plus le traitement par la suite est simplifié aussi.

J'ai aussi pensé à la clause LIMIT dans un premier temps, étant donné qu'il y a un minimum de 1 données par ligne. Je cherchais simplement une requête plus "optimisée". Mais je m'aperçois que ça reste amplement plus simple.

En tout cas j'aurais appris quelques trucs sur les limitations de MySQL. En revanche je ne pense pas passer à PostGreSQL dans l'immédiat. Mais j'y ai pensé aussi ^^

Pour le voc, je ne me fie en général pas aux traductions en informatique. Par exemple il existe le mot bogue. Mais on utilise plus souvent le mot anglais "bug" alors qu'une "traduction" existe officiellement (c'est donc elle et elle seule qu'on devrait utiliser). C'est ce qui fait que j'ai utilisé indifféremment "champ" et "colonne" ou "entrée" et "ligne", qui portent à peu près le même sens à me yeux en fonction qu'on s'intéresse à la forme ou à l'action.

Merci pour votre aide !

[CinePhil]

Je connaissais et je connais toujours ces principes de base. Mais j'ai fait le pour et le contre avec d'autres argument pratiques. Je fais effectivement une jointure avec une clé étrangère. Si je me limite à une donnée = une colonne, je peux avoir une ligne dans une table et 10 lignes dans une autre, et peut être que 2 pour une autre requête, bref, un truc pas très clair en définitive. C'est plus trivial dans mon cas au niveau du jeu de résultats. Ce qui m'avait motivé c'est ça (une ligne dans une table <=> une ligne dans une autre), ce qui rend la jointure simple et le nombre de lignes d'une table par rapport à l'autre raisonnable. En plus le traitement par la suite est simplifié aussi.

Sauf que faire ainsi c'est nier le principe même des bases de données relationnelles ! Autant utiliser un tableur !