Salut
dans le cadre du développement de phpmyvisites j'ai un probleme urgent à résoudre (et oui je bloque !).
 
Probleme :
une table SEQ contient des séquence sde nb
34;20;15
20;15;50
45;20;15
20;4
5;7;20
 
objectif : avoir en une requete unique si possible, les couples ET le nombre d'occurences de ces couples, "couple" étant l'ensemble de 2 valeurs X;Y avec X OU exclusif Y donné
exemple : je veux les couples 20;Y
il me retourne
20;15 | 3
20;4 | 1
 
astuce pour aider les valeurs peuvent être de taille fixe (5 caractères par ex. 20 serait 00020)
 
Merci d'avance si vous avez une idée de comment faire ça.
 
Il y a toujours la possibilité de sélectionner les couples différents  
- select champ from seq where champ like '%00020;_____%"
 
- (ici énorme traitement très bourrin pour sélectionner les couples uniques, compter les occurences de chaque)
 
- pour chaque couple unique 20;X
select count(*) from seq where champ like '%00020;X%'
 
mais ça ne me plait guère !
Ce n'est pas beau et c'est très lent.  
 
J'attends votre aide, merci  
Matthieu

je saisis pas trop  
combien de champs comporte ta table?

Hmmm... c'est chelou ton truc.
 
C'est sous quel SGBD ?
 
Tu veux une requête usine à gaz, ou si tu veux bien aussi de PS ?
 
T'es sûr que c'est pas un TP ? Je trouve que c'est trop bien énnoncé pour être un vrai problème

Bon, ben voilà, bête comme choux sous SQL Server :
 

 
Résultat :

 
Si seulement mes problèmes pouvaient être aussi simple !
 
 
PS: on peut faire différement avec des LIKE et des SUBSTRING dans tous les sens, mais laisse béton, tu ne trouveras pas de solution plus rapide que celle-ci.
 
PS²: Ouais, "PHPMyBiduleDeMerde", j'en déduis que tu bosses avec la bouse de MySQL. Ca tombe bien, il a un équivalent pour chacune des fonctions que j'ai utilisé. Par contre, faudra une version qui supporte les sous-requêtes.

J'ai mal lu? J'avais l'impression qu'on avait ce qu'il faut avec un bête

Ben nan, regarde ce qu'il veut comme résultat, ça ne marche pas aussi simplement.

Et les LIKE c'est pourri, c'est lent.

ah oui, mal regardé...

La bonne solution est
 

 
Mais  ça ne fonctionne pas quand il y a plusieurs 20:X dans la même ligne... est ce faisable dans ce cas là ? Je ne crois pas, mais qui sait ?

bien sûr sans procédures embarquées ou autres bizarreries... je ne demande qu'une requête unique.

ah au fait arjuna je viens de lire tes réponses... ça t'arrive d'être respectueux, aimable, voire les 2 à la fois ?
 
perso je dénigre totalement les gens qui bossent sous la m**** de SQLSserver mais tu vois je ne le dis pas..
et non ce n'est pas un TP excuse moi d'être confronté dans la vie avec des problèmes qui ressemblent peut être à des TPs.
 
et pour info, mysql supporte les sous requetes depuis qq années maintenant, donc chuuuuuuut...

allez on va pas se disputer pour un petit SGBD

 
Si tu savais le nombre de gens qui se pointent ici avec une version 3...

matthieu_p hpmv >
1/ Si j'étais pas respectueux, j'aurais pas daigné répondre
2/ Si ça t'emmerde de remercier quelqu'un qui a pris 15 minutes de son temps à te répondre, pose pas de questions
3/ La plupart des gens ici sont hébergés chez Free, qui ne dispose pas d'une version récente de MySQL, et qui ne supporte toujours pas les sous-requêtes
4/ Désolé de dire ce qui est, SQL Server est un des meilleurs SGBD du marché, MySQL un des pires, sauf pour quelques cas précis
5/ Ensuite, d'où je ne suis pas respectueux ? Tu bosses avec un outils de merde, j'y peux rien, t'y peux pas forcément plus. Tu t'appelles MySQL c'est ça ?

   
je veux bien que SQLsevrver soit un super SGBD mais ca ne fait pas de MySQL une merde (surtout dans ses versions recentes)
MYSQL a surtout l'avantage sur SQLServer de ne pas avoir obligatoirement a tourner sur un OS de merde

Les versions serveur de Windows récentes sont loin d'être comme Windows 95 hein, maintenant Win2K3 n'a pas grand chose à envier à Linux, mais bon, on ne va pas rentrer dans la polémique.
 
Sinon, je maintiens que même si MySQL tends à s'améliorer, il a encore énormément trop de défauts encore pour en faire un bon SGBD.
Le premier étant d'avoir fait passer la compatibilité Posix et Ansi avant la norme SQL (hors ce dernier n'est conforme avec aucune de ces deux normes)

tu me fait bien marrer avec ton argumentation.
Quand je critique un outil, il est évident que je le prend en dernière version.
"la version qui date de 4 ans, la 3.x, elle est toute nulle !!!"            
... pitoyable
 
 
ps : excuse de ne pas t'avoir remercié mais ça ne répondait pas vraiment à ma question... je voulais une seule requete. Enfin merci quand même.

pour info, free est en 4.0 pour mysql.. et effectivement
 "Starting with MySQL 4.1, all subquery forms and operations that the SQL standard requires are supported, as well as a few features that are MySQL-specific."

euh... j'ai qu'une seule requête hein. certes, y'a une sous-requête, mais y'a qu'une requête. les requêtes du haut sont juste la création de l'environnement de test (création de la table et insertion des données)
 
sinon, quand tu critiques sql server, ben c'est pareil, la 6.5 ouais, c'était de la merde en barre. la 7.0 c'était pas le pérou, mais ça restait incomparablement plus puissant que MySQL (y compris les derniers versions) quant à la version 2000 et la toute dernière 2005, y'a pas photo, mysql a encore au grand minimum 5 ans de travail acharné pour arriver à un niveau permettait de risquer une comparaison des produits.

 
alors celle la elle est ENORME
quand tu demandes un a ton epicier si il a des petits pois et qu'il va au fin fond de son magasin pour finalement ne pas en trouver tu te barres sans dire merci?

 
je croyais être le phénomène de l'analogie débile, mais là je crois que j'ai trouvé mon maître

   
 
Des annees de pratique
je n'ai aucun merite quand j'essaie de faire une analogie c'est automatiquement un truc a la con qui me sort

(en attendant, j'étais pas si loin que ça de la solution... )

sinon, un autre point qui pour moi reste très important aussi avec MySQL, c'est que comme la citation d'un film bien connu :
 
"ma maman me disait toujours que la vie est comme une nouvelle version de MySQL : on sait jamais sur quoi on va tomber"
 
Je fais référence à un bug rencontré récemment par un autre utilisateur du forum il y a quelque jours :
 
un "order by" portant sur un champ pouvant être NULL lui ramenait tous les NULL en premier, qu'il fasse un tri ASC ou DESC.
 
après recherche dans la doc de MySQL, il voit que MySQL n'est pas censé se comporter de la sorte depuis une certaine version x
Hors, il a une version y > x
Et... dans un autre chapitre de l'aide, bien caché entre deux paragraphes, il trouve le truc qui tue :
"ouais mais là en fait, dans la version x.a on a remis le bug sans le faire exprès, et on a laissé passé une version majeure et deux sous-version avant de s'en rendre compte et le re-corriger"
Résultat, il a dû changer de version de MySQL pour contourner ce problème.
 
Malheureusement (et c'est assez spécifique aux programmes open-source, mais bon, ça on n'y peut pas grand chose), c'est loin d'être un cas isolé.
 
Résultat, changer de version pour une version qui n'a plus ce bug, s'est s'exposer à autre bug qui fait partir en live une autre partie de l'application.
 
C'est un phénomène bien moins courant chez un logiciel éditeur.
Ceci dit, un éditeur n'est pas exempt de ce genre de conneries, il y a notamment l'épique trou de sécu de Windows 98, corrigé 5 fois de suite dans différents patchs : le codec de décompression JPEG contenait une faille de sécurité, qu'ils ont corrigé, puis ils ont écrasé la correction avec un autre patch, et on recorrigé, ré-écrasé et re-corrigé.
Ceci dit, ça reste bien plus rare qu'avec les applications open-source, mais c'est tout à fait compréhensible, puisqu'en open-source, la gestion des versions est plus complexe vu que chacun fait sa propre tambouille dans son coin et c'est pas toujours très bien centralisé.

oui, ma solution fonctionne dans tous les cas, et je maintiens, y'a qu'une seule requête

ma phrase est mal dite mais l'idée, c'est que EN PLUS de m'avoir limite insulté ""PHPMyBiduleDeMerde", j'en déduis que tu bosses avec la bouse de MySQL" (ce qui met en bouche il faut l'avouer, sacré ambiance), monsieur n'a pas répondu à ma question (je demande une requete, pas de sous requete sinon l'intérêt est déjà plus limité).
 
bref dans ma lancée j'ai oublié de remercier... je m'en excuse  

tu es pro-sqlserver, soit.
mais stp ne sors pas les vieux discours "le logiciel libre c'est pas bien c'est buggé et troué"... car bon je rappelle que mysql n'a que 9 ans, laissons leur le temps nécessaire pour arriver à la maturité des concurrents.
 
N'oublions pas non plus qu'eux n'ont pas derrière eux l'homme le plus riche prêt à financer à perte le R&D d'une filiale, étant sûr des apports réguliers et conséquents de cash. C'est tout de suite moins facile, mais tellement plus fun...
Rien que pour ça je suis fan.
 
Mais dans un environnement de prod ultra sécurisé ou rien ne doit être laissé au hasard, je remettrai mes opinions en question pour envisager peut être une meilleure solution si elle existe
 
mais pas de sqlserver restons corrects  

1/ "en une seule requête", ça n'exclu en aucun cas les sous-requêtes, désolé
2/ Si MySQL erst pénalisé par des sous-requêtes, alors ça justifie, sans besoin d'une ligne de plus, le fait que je le traîte de bouse infâme
 
Exemple :

 
Est rigoureusement équivalent (en temps et en résultat) à :

 
Si avec MySQL tu constates un différence aussi infime soit-elle, c'est que le moteur est clairement totalement à réécrire.

   
 
J'aime bien les discours sans detours!
 
Pour en revenir a la "norme" SQL , je suis relativement nouveau dans le monde des BDD (quelques mois seulement) mais les differents SGBD auxquels j'ai touche m'ont montre que pas grand monde en avait quelque chose a gratter de cette fameuse norme.
5 SGBD = 5 Syntaxes SQL differentes

Bof. Les grandes lignes sont les mêmes, si tu connais la norme correctement et que tu sais chercher dans la doc tu t'en sortiras toujours...

ca c'est sur mais on ne peut donc pas parler de norme SQL

j'ai pas dit "le logiciel libre c'est nul c'est buggé", j'ai dit que MySQL était victime ce que qu'on trouve souvent dans ce type de méthode de développement. y'a une légère nuance que tu n'as pas l'air de vouloir saisir.
 
ensuite, MySQL a 9 ans, ça tombe bien, SQL Server est bien plus récent, puisqu'entre la version 6.5 (version batarde de Sybase résultat d'un rachat de leurs sources) et la 7.0, il a été entièrement réécrit.
La 7.0 étant partie sur une voie pas très évolutive, le moteur de la 2000 a été lui aussi complètement réécrit. Seule la 2005 est une évolution directe du 2000, on peut donc conclure que si on laisse de côté l'expérience des équipes, SQL Server est bien plus jeune que MySQL.
 
Ensuite, Bilou est très loin d'être l'homme le plus riche de la planète. C'est peut-être même pas le plus riche de sa ville. Oui, il a une grande fortune à ses pieds. Mais il est loin d'être le seul, faudrait arrêter de lui reprocher d'avoir réussi sa vie.
Bettenceurt, Rockefeller ou Dupont de Neumours on aussi de la thune à ne plus savoir qu'en faire, largent autant que lui (ça coûte cher L'Oréal), et pour le dernier, messieurs de Neumours, ils font des médicament, ça ne les empêche pas de vendre leurs médocs à des prix exorbitants pour financer leur R&D.
 
Y'en a marre de lire cette fixation sur le fric à toutes les lignes, c'est pas parceque vous avez raté vos vies et que vous êtes frustrés qu'il faut reprocher celle de ceux qui ont réussi. Billou n'est pas né avec une tétine et un hochet en or, il l'a constitué tout seul sa fortune.

Sinon, je ne suis pas pro-sqlserver, je suis pro-trucsquimarchent, j'aime aussi énormément Oracle et DB2 par exemple, quoiqu'Oracle ça devient du total n'importe quoi en ce moment. Vu l'évolution des choses, MySQL dépassera Oracle avant de dépasser SQL Server.
Pour le moment, ce qui sauve Oracle, c'est qu'il est capable de tourner sur des machines 100 fois plus puissantes que des PC. Sauf que vu que SQL Server tire correctement partie de forêts de clusters de PC, ça revient au même et pour moins cher... y'a juste que l'infrastructure est un peu trop compliquée à maintenir ensuite.

ben...si. C'est pas parce-qu'aucun SGBD ne la suit qu'elle n'existe pas...

Pour en revenir à la question de départ, c'est aberrant de concaténer des nombres et ensuite espérer pouvoir écrire des requêtes simples utilisant cette table ...
 
Il faudrait plutôt gérer une table pouvant contenir les infos sous forme d'arbre, i.e. parent_nb, child_nb ...
Et là la requête est évidente.

je dis pas qu'elle existe pas je dis juste qu'o peut pas reprocher a MySQL de pas la suivre

je lui reproche pas de pas la suivre, je lui reproche d'en suivre deux autres qui n'ont rien à voir avec les outils de base de données

Genre, le caractère d'échappement d'une chaîne, en SQL92, c'est '' (l'apostrophe doublée).
 
Tous les SGBD supportent ce caractères (même MySQL, c'est pour dire) seulement, MySQL préconise, en toutes lettres, le caractère d'échappement ANSI qui est \', que seul MySQL et Oracle supportent, et qui n'a rien à voir avec la norme.
 
Idem avec les "
On en voit à toutes les sauces dans la doc de MySQL, hors c'est une abération, les " servant normalement à nommer un champ :
 

 
Résultat, d'un point de vue purement logique, c'est totalement débile d'interpréter les " comme un séparateur de chaîne, ça n'a aucun sens d'affecter une constante de chaîne à un champ : une constante de chaîne, ben ça n'a pas de nom.

SQL Server et Oracle par exemple auront ce comportement :

 
Je ne suis même pas sûr que MySQL est capable d'accepter cette syntaxe à cause de son interprétation du caractère "
 
Tu vas me dire qu'avec Access, on trouve aussi des " à toutes les sauces. Cependant, Access est un produit de merde (bien utile parfois mais bon), c'est pas une raison pour recopier ses âneries dans MySQL.

que dire sinon que tes competences en SGBD depassent totalement les miennes
sans etre aussi calle je n'ai pas l'impression que MySQL puisse etre qualifie de produit de merde pour toutes les raisons que tu as evoque.
En revanche je suis d'accord qu'un jugement objectif ammene a la conclusion qu Access est un produit de merde