Bonjour,
Tout est dans le titre à savoir : Je cherche l'équivalent de la fonction "Group_concat" sous SQL Server :)
Merci
Portekoi
Version imprimable
Bonjour,
Tout est dans le titre à savoir : Je cherche l'équivalent de la fonction "Group_concat" sous SQL Server :)
Merci
Portekoi
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 +
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 :)
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 +
"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 :
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)Code:
2
3
4
5
Si... 3 exemples parmi d'autres...Citation:
"MySQL étant faiblement relationnel " => ça ne veut rien dire.
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...
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...).Citation:
GROUP_CONCAT
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...
Transact SQL est né de Sybase SQL Server. A partir du rachat de ce moteurCitation:
Parce que le Transact-SQL de SQLServer, c'est de la norme ???
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...
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 .netCitation:
DECLARE @r varchar(255);
SET @r = '';
SELECT @r = @r + maColonne + ' ' FROM maTable;
SELECT @r;
A +
LIMIT est en tout point comparable à l'instruction TOP de SQL Server.Citation:
LIMIT propose que MySQL choisisse les lignes qu'il doive retourner
Ce n'est qu'une fenêtre de sélection, appliquée aux enregistrements que la requête retournerait sans l'instruction LIMIT.
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...Citation:
les solutions de sauvegarde de MySQL ne permettent pas à priori que la base reste intègre
Les instructions d'admin de MySQL offrent le minimum pour locker les tables, dans l'ordre que l'on veut.
En mode MyISAM, oui. En mode InnoDB, non.Citation:
Or MySQL en est encore à l'âge de pierre sur le sujet en stockant chaque table dans un fichier !
Vous en êtes restés à MyISAM.
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.Citation:
Si vous voulez réaliser une telle opération, alors vous pouvez parfiatement l'implémenter en respectant à la lettre la norme SQL:1999
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
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 !Citation:
Les instructions d'admin de MySQL offrent le minimum pour locker les tables, dans l'ordre que l'on veut.
A +
[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,exécute un dump de la totalité de la base dbname, au sein d'une transaction.Code:mysqldump --single-transaction dbname
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.
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.
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 +
Non, l'option --single-transaction ne verrouille pas la table, car elle travaille au sein d'une transaction.Citation:
Oui, mais cette sauvegarde vérouille la table pendant toute l'opération.
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.
Et à votre avis, une transaction, qu'est ce qu'elle fait ? Des cocottes en papier ou des verrous pour assurer la consitance transactionnelle ???Citation:
Non, l'option --single-transaction ne verrouille pas la table, car elle travaille au sein d'une transaction.
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).Citation:
j'ai trouvé le "gap" un peu plus important entre SQL Server et Oracle
A +
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
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 !!!Citation:
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
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 :
Donc en regardant à l'URL citée : http://sqlpro.developpez.com/cours/s...r/transactsql/Citation:
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
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 +