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 +