Discussion :

[-kiki-]

Allez... je vais vous faire dresser les cheveux sur la tête...

Oui GROUP_CONCAT est anti-relationnelle... ET ALORS?

Je suis d'accord l'ordre des lignes n'est pas un élément fiable, mais ce n'est pas pour autant qu'il n'existe pas! Ce n'est peut-être qu'une conséquence du système de stockage, mais tant que l'on stockera des bases de données dans des fichiers informatiques, il y aura bien un ordre!
Prendre du recul vis à vis de la théorie, et utiliser un fait (aussi anti-relationnel soit-il) pour créer une fonction pratique est-il blâmable? Je crois que c'est simplement la différence entre le "puriste" que vous êtes et le "bricoleur" qu'est le développeur de Mysql. La théorie est là pour nous guider, pas pour nous enfermer. (ouai j'aime bien les jolies phrases qui veulent rien dire )

Pour moi l'important c'est le résultat, pas l'idée : si l'utilisation de GROUP_CONCAT peut poser problème, alors ok, c'est une absurdité. Sinon, avouez qu'il est bien plus simple de faire un GROUP_CONCAT qu'une requête récursive!

I love GROUP_CONCAT !! (provoc' inside )

[CinePhil]

Oui GROUP_CONCAT est anti-relationnelle... ET ALORS?

Je suis d'accord l'ordre des lignes n'est pas un élément fiable, mais ce n'est pas pour autant qu'il n'existe pas!

Euh... quel est le rapport en GROUP_CONCAT et l'ordre d'enregistrement des lignes dans la table ?

GROUP_CONCAT est fait pour mettre dans une seule colonne de résultat les différentes valeurs d'une colonne de la table, en regroupant ces dernières selon la valeur dune ou d'un ensemble d'autres colonnes. Aucune notion d'ordre là-dedans !

L'ordre est donné par ORDER BY !

[SQLpro]

Au sujet de GROUP_CONCAT....
Vous oubliez une seule chose : la clause ORDER BY est censée faire un tri des lignes du résultat. Pas de trier les lignes AVANT de publier le résultat...

Méditez sur le chose et dites moi quelles sont les problèmes :
1) pour des sous requêtes imbriquées avec une telle clause
2) pour obtenir de bonnes performances

A +

[Maljuna Kris]

GROUP_CONCAT est fait pour mettre dans une seule colonne de résultat les différentes valeurs d'une colonne de la table, en regroupant ces dernières selon la valeur dune ou d'un ensemble d'autres colonnes. Aucune notion d'ordre là-dedans

Juste une précision, la fonction GROUP_CONCAT() peut intégrer une clause ORDER BY qui lui soit propre.

[Waldar]

Oracle dans sa dernière version a intégré officiellement l'équivalent de GROUP_CONCAT avec LIST_AGG.

Il est possible de créer de UDA (User Defined Aggregate) depuis la version 9i et l'équivalent de GROUP_CONCAT est sûrement une des fonctions qui a été la plus codée (difficile de nier son intérêt dans un reporting).

Les solutions purement SQL existent depuis à peu près la 9i (récursivité, utilisation des fonctions XML...), donc c'était une bonne chose de l'implémenter nativement.

D'ailleurs on peut obtenir la même chose chez SQL-Server avec en utilisant FOR XML PATH

Là où je suis parfaitement d'accord avec SQLPro, c'est que cassant la théorie relationnelle, ces fonctions ne doivent servir que pour faire de la consultation de données.

[SQLpro]

En SQL Server tu peut faire la même chose via une UDA .net. Exemples :
http://www.insystusa.com/Blog/2009/1...Aggregate.aspx
http://geekswithblogs.net/tonyt/articles/70274.aspx

A +

[-kiki-]

GROUP_CONCAT est fait pour mettre dans une seule colonne de résultat les différentes valeurs d'une colonne de la table, en regroupant ces dernières selon la valeur dune ou d'un ensemble d'autres colonnes. Aucune notion d'ordre là-dedans

Juste une précision, la fonction GROUP_CONCAT() peut intégrer une clause ORDER BY qui lui soit propre.

oui et l'idée de départ était :
-GROUP_CONCAT est stupide car anti-relationnelle
-GROUP_CONCAT est anti-relationnelle car elle "nécessite un ordre de lecture" et que "la théorie des ensemble suppose une absence d'ordre totale dans les lignes"

Méditez sur le chose et dites moi quelles sont les problèmes :
1) pour des sous requêtes imbriquées avec une telle clause
2) pour obtenir de bonnes performances

Ok, là on est plus dans la théorie...
j'ai le droit de faire mon chieur et dire que de toute façon je préfère les jointures aux requêtes imbriquées?
Non?
OK... Je médite et je reviens

[SQLpro]

...
j'ai le droit de faire mon chieur et dire que de toute façon je préfère les jointures aux requêtes imbriquées?
Non?
OK... Je médite et je reviens

Vous avez le droit, mais cela ne même à rien car certaines requêtes ne peuvent pas être exprimées uniquement à base de jointures.
C'est comme si vous disiez je préfère le vélo à la psychologie !!!

A +

[-kiki-]

Vous avez le droit, mais cela ne même à rien car certaines requêtes ne peuvent pas être exprimées uniquement à base de jointures.
C'est comme si vous disiez je préfère le vélo à la psychologie !!!

A +

je sais, mais vue la (non) complexité de mon taff, ça m'arrive très très rarement (d'être obligé d'imbriquer).
et de toute façon c'était juste un peu d'humour pas drôle
j'ai l'air d'une bille à ce point pour que vous preniez ce genre de remarque au sérieux?

en résumé je voulais dire "argument retenu. Je vais y réfléchir"

[kedare]

Le problème de MySQL n'est pas tant la rapidité de lecture, que celle transactionnelle. En lecture il est plutôt bon. En écriture en concurrence c'est catastrophique. A plus de 5 utilisateur il plonge dramatiquement ! Alors que Oracle ou SQL Server parviennent à plusieurs milliers d'utilisateurs simultanément, sans broncher....

A quel prix ?
C'est clair que SQL Server explose MySQL sur a peu pret tout, mais faut voir si ca vaut vraiment le coup de le payer...

D'ailleurs petite question, tu pense que c'est une bonne idée d'utiliser SQL Server Express Edition (2008 R2) en production ? (Sachant que la limite des 10Go et d'un seul CPU (Mais plusieurs cores...), n'est pas un problème ? C'es clair que c'est dommage de se priver du profiler mais bon...

J'ai un petit projet qui tourne avec une base SQL Server 2008 R2 Express (environ 500.000 lignes, quelques centaines de Mo), ca tourne impec, mais c'est clair qu'il manque par exemple un programme pour pouvoir logger les requêtes SQL (Bon j'ai accès aux rapports pour avoir les requêtes les plus gourmandes en IO et CPU, ca aide déjà bien.. ;p), et aussi les programmes de maintenances automatisé manquant... C'est pas très pratique de devoir faire ça dans SSMS manuellement, mais bon ça doit être automatisable via tâches planifiées)

[SQLpro]

A quel prix ?
C'est clair que SQL Server explose MySQL sur a peu pret tout, mais faut voir si ca vaut vraiment le coup de le payer...

N'oubliez jamais que MySSL est payant !
En effet, soit il vous faut payer en mettant le code applicatif à disposition de MySQL devenu Oracle, ou si vous ne voulez pas livrer votre code, il faut payer. Impensable pour un éditeur applicatif de ne pas payer, même si certains ne respectent pas le contrat en ne payant rien à MySQL et en refusant de délivrer le code. Mais moi je me souviens du coup que Compuserve à fait avec le format d'image .GIF dont il était le propriétaire...
A lire : http://en.wikipedia.org/wiki/Graphic...rchange_Format
rubrique "Unisys and LZW patent enforcement" :
In August 1999, Unisys changed the details of their licensing practice, announcing the option for owners of Billboard and Intra net Web sites to obtain licenses on payment of a one-time license fee of $5000 or $7500.[18]

D'autre part MySQL est très limité dans beaucoup de ses fonctionnalités. Ce que j'ai appelé les fonctionnalité poudre aux yeux. Quelques exemples : indexation textuelle inutilisable (voir mon dernier livre sur SQL ou je compare les deux moteurs), le SIG (inexploitable en pratique), technique de haute disponibilité ridicules. Ainsi on voit des éditeurs se précipiter sur MySQL parce que c'est gratuit et ensuite investir très cher dans des techno complémentaires du fait des manques... Et la le bilan global devient catastrophique : ressources à multiplier par 3 ou 4, licences externes à payer très cher, complexité de maintenance et de déploiement accrues, savoir faire rare à trouveret payer pour le coup très cher... Tout cela pour du soit disant gratuit. Au moins Microsoft est cohérent et fournit un ensemble complet et suffisant d'outils dont la plupart sont intégrés directement à SQL Server...

D'ailleurs petite question, tu pense que c'est une bonne idée d'utiliser SQL Server Express Edition (2008 R2) en production ? (Sachant que la limite des 10Go et d'un seul CPU (Mais plusieurs cores...), n'est pas un problème ? C'es clair que c'est dommage de se priver du profiler mais bon...

Le profiler SQL est un outil client. Vous pouvez donc parfaitement l'utiliser avec SQL Server Express. Il vous suffit pour cela d'acheter une licence développement pour pouvoir utiliser tous les outils clients sur tous les serveurs SQL de votre entreprise qu'ils soient Express ou non. Or une licence développeur c'est moins de 70 € !

J'ai plusieurs clients qui utilisent SQL Server Express en production. D'ailleurs de nombreux éditeurs proposent dans leur entrée de gamme la version Express.
L'un de mes client héberge plusieurs dizaine de bases sur la même instance. Mais c'est vrai que le nombre des utilisateurs est faible.
Enfin, avec la virtualisation, rien ne vous empêche de lancer 10 serveurs Windows avec chacun son SQL Server et 2 Go de RAM pour héberger
différentes bases... Vous ne payerez donc qu'une seule licence, celle de Windows au nombre de CPU physique !!!

J'ai un petit projet qui tourne avec une base SQL Server 2008 R2 Express (environ 500.000 lignes, quelques centaines de Mo), ca tourne impec, mais c'est clair qu'il manque par exemple un programme pour pouvoir logger les requêtes SQL (Bon j'ai accès aux rapports pour avoir les requêtes les plus gourmandes en IO et CPU, ca aide déjà bien.. ;p), et aussi les programmes de maintenances automatisé manquant... C'est pas très pratique de devoir faire ça dans SSMS manuellement, mais bon ça doit être automatisable via tâches planifiées)

Même remarque que précédemment. Mais pour l'agent SQL, vous pouvez utiliser des tâches planifiées dans l'OS WIndows puisque Windows a son propre scheduler !

A +

[kedare]

Enfin, avec la virtualisation, rien ne vous empêche de lancer 10 serveurs Windows avec chacun son SQL Server et 2 Go de RAM pour héberger
différentes bases... Vous ne payerez donc qu'une seule licence, celle de Windows au nombre de CPU physique !!!

Il faut pas payer une licence Windows Server par VM ?

[SQLpro]

Le paiement se fait par CPU physique...

Vous pouvez donc avoir 10 VM sur une machine 4 CPU, vous ne payez que pour les 4 CPU !!!

A +