Discussion :

[Portekoi]

Bonjour,

Tout est dans le titre à savoir : Je cherche l'équivalent de la fonction "Group_concat" sous SQL Server

Merci


Portekoi

[SQLpro]

Group_concat n'existe pas dans la norme SQL. SQL est un langage normatif et SQL Server un SGBDR assez respectueux de la norme.

Sois donc un peu plus explicatif !

A +

[Portekoi]

Ah désolé, je pensais que c'était connu comme fonction. Elle est implémenté dans Mysql et permet de groupé sur une ligne plusieurs enregistrements

Plus d'infos ici : http://dev.mysql.com/doc/refman/5.0/...functions.html

Merci

[SQLpro]

MySQL étant faiblement relationnel utilise tout un tas de fonctions particulièrement anti relationnnelle qui n'ont pas sa place dans un SGBDR digne de ce nom.

S'agissant de cosmétique de données, je vous conseille d'exécuter cela sur le client, sinon développer vous même une fonction pour ce faire.

J'attire cepandant votre attention sur le fait que les spécifications de cette fonction ne sont pas déterministe et que donc le résultat que vous pouvez avoir avec un même jeu d'esais peuvent différer d'une exécution à l'autre.

A +

[babar75]

"MySQL étant faiblement relationnel " => ça ne veut rien dire.

Comme SQL Server, MySQL5 a un mode transactionnel ACID (avec InnoDB), des clefs primaires, des contraintes d'intégrité référentielle, des indexes (B-Tree, R-Tree), des vues, etc.
MySQL est simplement très populaire, ce n'est pas une raison pour le dénigrer.

"S'agissant de cosmétique de données, je vous conseille d'exécuter cela sur le client"

=> GROUP_CONCAT permet précisement d'éviter de réaliser des boucles côté client, ce qui, lorsque les boucles sont mal faites (genre un SELECT par itération), est une mauvaise pratique.
Par ailleurs, MySQL n'a pas de fonctionnalité XML pour le moment, et GROUP_CONCAT m'a facilité la tâche pour réaliser certains types d'exports XML (dans le cas de relations n-n).

"les spécifications de cette fonction ne sont pas déterministe "
=> à ma connaissance, GROUP_CONCAT n'est pas moins déterministe que GROUP BY.
S'il est éxecuté avec sa clause interne ORDER BY (GROUP_CONCAT(expr ORDER BY col) ), il est aussi déterministe qu'une requête SQL simple.

"Group_concat n'existe pas dans la norme SQL"
=> Parce que le Transact-SQL de SQLServer, c'est de la norme ???

C'est d'ailleurs avec du Transact qu'on arrive à simuler GROUP_CONCAT sous SQL Server :

Code :

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

1
2
3
4
5
 
DECLARE @r varchar(255);
SET @r = '';
SELECT @r = @r + maColonne + ' ' FROM maTable;
SELECT @r;

On n'aura malheureusement pas la même concision et la même souplesse d'emploi qu'avec GROUP_CONCAT (cf. ses clauses internes DISTINCT et ORDER BY)

[SQLpro]

"MySQL étant faiblement relationnel " => ça ne veut rien dire.

Si... 3 exemples parmi d'autres...
1) un certain nombre d'opérateurs tel que LIMIT sont anti relationnel. En effet une table étant un ensemble de données il n'y à pas d'ordre. Or LIMIT propose que MySQL choisisse les lignes qu'il doive retourner. C'est une hérésie sur le plan de relationnel !
2) les solutions de sauvegarde de MySQL ne permettent pas à priori que la base reste intègre. En effet la sauvegarde étant faite table par table ou par un DUMP (ce qui revient au même), on peut se trouver dans la situation ou la table commande est sauvegardée après la table client et contient des commandes d'un client qui a été inséré entre temps. A la restauration la base sera donc inconsistente, les données corrompues, la base inutilisable...
3) le Dr. Codd père fondateur des SGBDR a indiqué dans plusieurs de ses règles (8, 9, 11) que les données dévaient être indépendante des problématiques physique de stockage (fichiers). Or MySQL en est encore à l'âge de pierre sur le sujet en stockant chaque table dans un fichier ! Ceci etait l'apanage des bases de données dites "fichiers" des années 80, types de bases de données qui ont aujourdh'ui presque totalement disparues...

GROUP_CONCAT

Le problème est que SQL est un langage normalisé afin d'être protable. Or MySQL est très loin de respecter la norme. Si vous voulez réaliser une telle opération, alors vous pouvez parfiatement l'implémenter en respectant à la lettre la norme SQL:1999 que MySQL n'a malheureusement pas encore implémenté (il a déjà du mal avec celle de 1992 alors...).
Lisez l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...te-recursives/
Vous trouverez un exemple de CTE utilisant une concaténation des noms de villes pour trouver un chemin dans un graphe modélisant un parcours routier...

Parce que le Transact-SQL de SQLServer, c'est de la norme ???

Transact SQL est né de Sybase SQL Server. A partir du rachat de ce moteur
par Microsoft, ces derniers n'ont pas cessé de porter la syntaxe vers la norme. Petits exemples : la fonction d'obtention de la date/heure système était dans Sybase SQL Server, GETDATE(). La norme imposait CURRENT_TIMESTAMP. La fonction CURRENT_TIMESTAMP a donc été rajoutée par les équipes de développement de Microsoft, tout en conservant GETDATE() pour des raisons de rétro compatibilité. En revanche les anciennes syntaxes de jointures externe hors norme de Sybase SQL Server à la *= ou =* ou *=* ont été définitivement retirées du moteur à partir de la version 2005...
En tout état de cause SQL Server s'avère très proche de la norme SQL, même s'il existe quelques notables différences...

DECLARE @r varchar(255);
SET @r = '';
SELECT @r = @r + maColonne + ' ' FROM maTable;
SELECT @r;

Bien que j'ai donné il y a longtemps cette syntaxe, (voir els exemple dans http://sqlpro.developpez.com/cours/s...ransactsql/)il n'est pas conseillé de l'utiliser en production car l'ordre des données peut s'avérer aléatoire. La seule véritable solution est de passer soit par une CTE, soit d'ajouter votre propre fonction d'aggrégation en la codant en .net

A +

[babar75]

LIMIT propose que MySQL choisisse les lignes qu'il doive retourner

LIMIT est en tout point comparable à l'instruction TOP de SQL Server.
Ce n'est qu'une fenêtre de sélection, appliquée aux enregistrements que la requête retournerait sans l'instruction LIMIT.

les solutions de sauvegarde de MySQL ne permettent pas à priori que la base reste intègre

Heureusement que si. Vous n'êtes manifestement pas conscient du nombre de backups MySQL qui sont réalisés chaque jour dans le monde, sur des plateformes très sollicitées...
Les instructions d'admin de MySQL offrent le minimum pour locker les tables, dans l'ordre que l'on veut.

Or MySQL en est encore à l'âge de pierre sur le sujet en stockant chaque table dans un fichier !

En mode MyISAM, oui. En mode InnoDB, non.
Vous en êtes restés à MyISAM.

Si vous voulez réaliser une telle opération, alors vous pouvez parfiatement l'implémenter en respectant à la lettre la norme SQL:1999

Il me semble que les requêtes récursives visent la résolution de problèmes plus complexes que ceux que l'on résoud, de façon concise, avec un GROUP_CONCAT.
MySQL implémentera peut-être un jour ce fameux WITH. Je l'espère.
Notez que sur cette question précise, la "norme" est diversement mise en pratique (Oracle a ses propres instructions).

Enfin, par rapport à ce que vous dîtes sur CURRENT_TIMESTAMP, franchement, vous me faîtes sourire... Tout le monde sait très bien que chaque base de données a développé sa propre extension du langage SQL. Que ce soit TransactSQL de SQLServer, PL/SQL d'Oracle, ou les petits ajouts propres à MySQL, chacun y va de son dialecte, c'est parfaitement assumé par les BD elles-mêmes, et SQLServer regorge de petites instructions bien à elle. Le contraire serait d'ailleurs étonnant, de la part de Microsoft, habitué à "emballer" les normes de ses propres fioritures et ajouts divers.

PS : CURRENT_TIMESTAMP existe aussi sous MySQL

[SQLpro]

Les instructions d'admin de MySQL offrent le minimum pour locker les tables, dans l'ordre que l'on veut.

Donc on ne peut pas faire de sauvegarde à chaud alors que c'est possible dans la plupart des autres produits : Oracle, IBM Db2, SQL Server, PostGreSQL, InterBase, Firebird !

A +

[babar75]

[QUOTE=SQLpro;2759028]Donc on ne peut pas faire de sauvegarde à chaud alors que c'est possible dans la plupart des autres produits : Oracle, IBM Db2, SQL Server, PostGreSQL, InterBase, Firebird !
QUOTE]

A chaud,

Code :

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

mysqldump --single-transaction dbname

exécute un dump de la totalité de la base dbname, au sein d'une transaction.

Une fois encore, je pense que vous en êtes resté à MyISAM.
Jetez un oeil sur InnoDB : vous verrez que MySQL n'a rien de méprisable.

[djlixfe]

On ne dit pas que mysql est méprisable, mais elle est assez éloignée de la norme, ce qui ca rend les migrations difficiles.

[SQLpro]

Oui, mais cette sauvegarde vérouille la table pendant toute l'opération. Donc :
soit vous ne pouvez plus faire en sorte que vos utilisateurs travaillent, soit vos sauvegardez dans le passé...

Aujourd'hui la plupart des SGBDR savent faire des sauvegardes à chaud, sans perturber le travail des utilisateurs et en mettant dans la sauvegarde toutes les modifications intervenues depuis le début de la sauvegarde. Exemple si je démarre ma sauvegarde à minuit et qu'elle se termine à 2h du mat, ma sauvegarde contient l'état de la base à 2h du mat et non l'état à minuit...

A +

[babar75]

Oui, mais cette sauvegarde vérouille la table pendant toute l'opération.

Non, l'option --single-transaction ne verrouille pas la table, car elle travaille au sein d'une transaction.
J'imagine que c'est aussi grâce à un mécanisme transactionnel que SQL Server, Oracle ou Sybase peuvent faire leurs dumps à chaud.

Quant au respect des normes, SQL Server a été la première base avec laquelle j'ai travaillé dans ma carrière, avant de passer à Oracle et MySQL.
Eh bien, du point de vue des requêtes, j'ai trouvé le "gap" un peu plus important entre SQL Server et Oracle, qu'entre SQL Server et MySQL - enfin, ce fut mon impression...

Attention, je ne dis pas que MySQL est supérieur à SQL Server.
Je réagis juste à ce post, parce que SQLPro écrit des énormités au sujet de MySQL, et pour quelqu'un qui s'affiche comme Pro, je trouve que ça ne le fait pas, voilà. Il maîtrise certainement très bien SQL Server, mais pas MySQL.

[SQLpro]

Non, l'option --single-transaction ne verrouille pas la table, car elle travaille au sein d'une transaction.

Et à votre avis, une transaction, qu'est ce qu'elle fait ? Des cocottes en papier ou des verrous pour assurer la consitance transactionnelle ???

j'ai trouvé le "gap" un peu plus important entre SQL Server et Oracle

Tout à fait normal, Oracle ne respecte pas plus la norme SQL que mySQL. Cepandant la plupart des fonctions requises par les normes SQL2 et SQL:1999 sont présente dans oracle (mais la syntaxe est très différente).

A +

[david.keller]

le but d'un forum de discussion est d'échanger entre nous et de trouver des solutions pour répondre à la question posée, pas de partir dans des jugements de valeur tels que : Mysql mieux que SQL Server, la pêche à ligne c'est mieux que le yoga, l'OM c'est mieux que le PSG, etc. On s'en fout et cela fait pas avancer le débat.

si on est prétendu expert dans un domaine, on ne nous demande qu'une seule chose, très factuelle c'est : trouver la solution

bien que je ne sois pas expert en SQL Server, j'ai trouvé une solution ici (en anglais) :

http://blog.shlomoid.com/2008/11/emu...-function.html

[SQLpro]

si on est prétendu expert dans un domaine, on ne nous demande qu'une seule chose, très factuelle c'est : trouver la solution

Sans doute es-te vous aveugle ou bien vous ne comprenez pas le français... Je vous ais donné 2 solutions... Celle que vous avez trouvé est sans doute la pire de celles que je vous ais proposées et terme de performances !!!
Deuxièmement, vu le nombre de réponse que je donne (plus de 6000 à ce jour, - la différence vient du fait que j'en ai effacé un bon nombre...), je pense que je n'ai de leçon de recevoir de personne.
Troisièmement, un forum de discussion est fait pour discuter et non pour vous apporter tout cuit une solution. Pour ce qui est de vous apporter tout cuit une solution, mon tarif va de 650 € HT /jour pour des choses simples sans compte rendu et en région PACA à 1200 € HT /jour pour des audit, et pour ce faire vous pouvez me joindre par le biais de mon entreprise SQL spot :
http://www.sqlspot.com

Il y a même quelqu'un qui à repris cette solution, et voici ce sue j'en ais dit :

Bien que j'ai donné il y a longtemps cette syntaxe, (voir els exemple dans http://sqlpro.developpez.com/cours/s...ransactsql/)il n'est pas conseillé de l'utiliser en production car l'ordre des données peut s'avérer aléatoire. La seule véritable solution est de passer soit par une CTE, soit d'ajouter votre propre fonction d'aggrégation en la codant en .net

Donc en regardant à l'URL citée : http://sqlpro.developpez.com/cours/s...r/transactsql/
dernier exemple du paragraphe 2.8

Pour la solution sous forme CTE, il suffisait de regarder l'article que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/s...te-recursives/
et notamment le paragraphe 10 :
http://sqlpro.developpez.com/cours/s...recursives/#LX

Ext-ce au dessus de vos force de chercher un tantinet par vous même ???

A +