Reprise du message précédent :
Oui ^^
J'ai crut pouvoir gruger en mettant le MAX dans le groupe principal mais comme l'alias ne fonctionne pas ça ne sert à rien...
Mon pavé au dessus c'était pour répondre à flo850 qui proposait une solution sans INNER JOIN (SELECT), qui est peut être plus performante, faudrait tester, mais je suis content de découvrir l'astuce des alias permettant de rendre "accessible" des clause provenant de GROUP BY, je suis sur que ça me resservira !

Bonjour bonnes gens, je mets ça ici mais je sens que c'est plutôt dans la section VB/VBA que je vais devoir aller

Je vais simplifier au maximum : imaginons que j'ai une table Produits (avec juste un Id et un libellé), et une table d'historique des Transactions (avec, disons, la référence à l'id du produit, un nom d'acheteur, et une date pour la forme). Rien de compliqué, ni même dans qu'il faut obtenir : avoir l'historique des transactions par produit. Une bête requête et on aura le résultat sous cette forme (prenons des denrées très rares pour l'exemple ) :

Maintenant, pour des raisons diverses et variées ( ), j'ai besoin d'un résultat sous cette forme là dans un export en fichier texte brut en fixed-width pour chaque champ :

--> En gros, avoir un groupement par produit, mais pas sous un bête GROUP BY classique : le produit doit apparaître une seule fois, et en dessous on doit avoir l'historique des achats.

On est bien d'accord qu'il n'y a rien en SQL qui me permette d'obtenir ça, right ?  
(En standard, j'entends. J'ai pas accès à quoique ce soit qui me permette de faire du T/PL-SQL ou autre truc plus avancé. On va dire que je serai limité à Access )

J'ai tenté de bricoler en VBA, mais je crois que c'est mort, j'suis trop mauvais pour ça  

Non, tu ne pourras pas avoir cette forme avec du SQL pour la bonne et simple raison que les colonnes so différentes :
La première ligne, t'as le nom du produit et c'est (tout), 1 colonne donc et les lignes suivantes, 2 colonnes portant sur des champs différents.
Un BD, c'est fait pour du stockage de données et leur recherche/extraction et éventuellement du traitement mais pas pour de la mise en forme

Ok merci, c'est bien ce que je me disais
Bon, bah j'vais voir pour bricoler un truc en VBA

Je suis sûr que c'est faisable avec des natasseries oracle

en postgresql avec des array_agg bien sales aussi, mais c'est vraiment tordre le truc

array_agg va te permettre de collecter les données (et c'est pas bien sale pour le coup) mais pour le formattage faudrait du PL parce-que le groupby sortirait un truc style
 
01, RTX3080, ARRAY[ARRAY[HFRien_A, 2021-06-01], ARRAY[HFRien_B, 2021-05-01]]
02, RX6800, ARRAY[ARRAY[HFRien_C, 2021-04-01]]
03, RTX3060, ARRAY[ARRAY[HFRien_D, 2021-03-01], ARRAY[HFRien_E, 2021-02-01]]

après tu colles les tableaux avec des sauts de lignes
 
Mais je pense qu'il vaut mieux un bout de langage de script pour faire ça

À coup de string_add sur la subquery? Je comprend mieux ta déclaration que ce serait sale, effectivement

Je ne dis pas que c'est impossible,je dis juste que c'est pas fait pour. Je suis old-school. Une BD, c'est pas censé faire du traitement, la logique métier, c'est l'appli qui doit s'en charger. La BD doit juste faire le stockage en l'optimisant et permettre la recherche, le CRUD et l'extraction des données rapidement. C'est déjà pas mal
Perso, je suis pas fan de tout ce qui est trigger et procédures stockées. Commencer à mettre de l'applicatif dans la BD, séparé du reste du code de l'appli, c'est un bon moyen de créer des pbs je trouve...

C’est plus du middle-scool ou du new-school en fait, tu remarqueras que les DBS nosql tu peux rien faire dedans, mais les RDBMS les plus big-iron ont toutes des extensions procédurales

Clairement, le vrai old school c'est du Oracle forms/reports où l'installation de l'environnement de développement demande déjà de créer un schéma dans une base Oracle...

Je parlais du old-old-school Avant qu'Oracle & co se mettent à inventer les procédures stockées, du temps où une BD faisait que ce que je décrivais, genre Paradox (oui, c'est pas tout jeune   ). Après, y'a eu ce que tu décrivais et aujourd'hui on en revient. Bref, comme souvent, mouvement de balancier : on commence sur une tendance puis on va vers une autre à l'opposée puis on revient en arrière et ainsi de suite jusqu'à trouver le bon équilibre.
 
UN peu comme avec l'Objet où une catégorie de dév en revient et des langages comme Python qui ont pas mal alléger le concept qui était devenu trop complexe/lourd en C++/Java (par ex).

Je viens de passer 25 minutes à écrire un post décrivant mon problème, tout ça pour finir par le résoudre en 30 secondes une fois le post terminé.
 
Merci à tous pour votre aide

classique
 
gg

Oui, un grand classique. Ou alors, tu postes ta question et quelques minutes après, tu finis par trouver la solution par toi-même  

 
C'est plus ou moins du rubber duck debugging : https://en.wikipedia.org/wiki/Rubber_duck_debugging

Merci, je ne connaissais pas.

Excellent
 
J'avais tenté le coup en expliquant à ma copine sans lui donner le moindre contexte, ça ne m'avait pas aidé ceci-dit

Bijour les gens , ce lancer dans du sqlite pour un ptit projet , folie ou y'a mieux ?  
 
je cherche à pouvoir rentrer des truc dans une base de donnée dont j'aurais décider de la structure avec un moyen graphique de manipuler certaine donnée , extraction vers des formats de gueux inclus (csv, json , xml).
 
pour l'instant je trouve que slite et SQLite GUI tools pourrais faire le job, la bdd je la gère en conf sous GIT de façon régulière et c'est marre ?
 

Dépend de l'échelle du projet, sqlite marche très bien tant que t'as pas trop trop d'écritures (même en mode WAL ça reste single-writer). Si t'as quasiment que des lectures tu peux faire des milliers de requêtes (SQL) par seconde.

Selon ton archi, tu peux vouloir envoyer toutes les écritures sur une queue pour t'assurer qu'un seul thread ou process écrit à la fois, si non une option commune est BEGIN IMMEDIATE si tu sais que tu vas avoir besoin d'écriture (autrement la connection est upgradée de READ à WRITE au besoin ce qui peut être bof), penser à regarder ce que ton driver de DB met comme busy_timeout, et à le configurer si c'est le défaut (0).

Effectivement j'ai oublié de préciser : c'est pas du tout pour un acces web par plusieurs personnes en meme temps.
 
en fait c'est pour remplacer un putain de fichier Excel partagé assez gros et horrible à manipuler (~10k lignes avec pas mal d'onglet)

C'est quoi le best practice pour trier des résultats dans une jointure, la sous requête ?
J'ai 16 000 produits et 4000 catégories repartis dans une dizaine de shop (en tout environ 200k+ association produits a des catégories).
Pour m'y retrouver dans le classement de produits je voudrais les catégories de niveau le plus profond possible, pacque oui le produit peut être à la fois dans la racine "jouet" et dans son enfant "maquette" voir même dans sa sous sous categorie "maquette d'avion", pour mon export maquette d'avion est plus qualifiant.
Soyons plus concret :

SELECT prod.*, categ.`name`
FROM `product` prod
INNER JOIN `category_product` catprod ON catprod .`product_id` = prod.`entity_id`
INNER JOIN `category` categ ON categ .`entity_id` = catprod.`category_id`
WHERE 1
GROUP BY prod.`entity_id`

A l'heure actuelle le SGBD choppe bien la catégorie qu'il veut bien trouver...
Sachant aussi que bien sur, le level est au niveau de la category (ce que je voudrais trier, pour garder la catégorie ayant le chiffre le plus élevé).
 
La solution optimal à votre avis ce serait de faire un truc de ce genre ?

SELECT prod.*, categ.`name`
FROM `product` prod
INNER JOIN `category` categ ON categ .`entity_id` = ( SELECT catprod.`category_id`
                                                      FROM `category` categ
                                                      INNER JOIN `category_product` catprod ON catprod .`product_id` = prod.`entity_id`
                                                      WHERE 1
                                                      ORDER BY categ.`level` DESC
                                                      LIMIT 1 )
WHERE 1

Bon en vrai mon problème sera plus compliqué car c'est un magento < 2 et les données sont soient dans des tables varchar / int / text / etc., ou alors dans une table d'index mais y'en a 10 (une par boutique).

un truc du genre?

SELECT prod.*, categ.`name`
FROM `product` prod
INNER JOIN `category_product` catprod ON catprod .`product_id` = prod.`entity_id`
INNER JOIN `category` categ ON categ .`entity_id` = catprod.`category_id`
LEFT OUTER JOIN `category` categ2 ON categ2 .`entity_id` = catprod.`category_id` AND  categ2.level > categ.level
WHERE categ2.id IS NULL

(il manque un left join, là, il faut doubler le lien category_product aussi, je suis allé trop vite)

[edit]

plutôt ça si je me suis pas encore planté, donc

SELECT prod.*, categ.`name`
FROM `product` prod
INNER JOIN `category_product` catprod ON catprod .`product_id` = prod.`entity_id`
INNER JOIN `category` categ ON categ .`entity_id` = catprod.`category_id`
LEFT OUTER JOIN `category_product` catprod2 ON catprod2 .`product_id` = prod.`entity_id`
LEFT OUTER JOIN `category` categ2 ON categ2 .`entity_id` = catprod2.`category_id` AND  categ2.level > categ.level
WHERE categ2.id IS NULL

Au lieu d'une sous-requête pour chercher le niveau le plus haut on rajoute de quoi filtrer pour ne prendre que les cats pour lesquelles il n'existe de de lien vers une autre cat avec un level plus élevé.

Un truc du genre?  Je sais pas si substr est le bon operateur pour ton SGBD  
 
 
 

 
L'idée du level+10000000000  est qu a priori y a peu de chance que tu aies des level > 10000000000  
Donc le max(level+10000000000+name) te renverra un truc du genre "100000135478maquetted'avion" si le level de maquetted'avion est 135478 .
Et ensuite tu enleves les chiffres avec le substr  

 
Je comprends pas bien ce que t'essayes de faire
Le résultat va dépendre de la longueur du champ categ.name là non?

Suppose que tu aies 2 categ pour ton produit :
- une avec level = 103 en name = "truc"
- une avec level = 12 en name = "machin"
=> categ.`level`+10000000000 + categ.`name`donne
10000000103truc
10000000012machin

Quand je teste sur Oracle, la max donne 10000000103truc
Et avec
10000000103machin
10000000012truc
la max donne 10000000103machin
Donc, au moins sur Oracle, le tri lexicographique privilégie bien le nombre au début de la chaine de car. plutot que la longueur de la chaine  , et du coup ca marche
Mon test :

> categ_max = truc

> categ_max = machin

ok, à voir si ça se comporte pareil sur tous les sgbd.
 
Je préfère quand même ma solution cela dit

La mienne est plus performante en principe

 
Faut voir, tu fais un max sur une chaine calculée donc pas indexée, contre des jointures sur des ids...

Merci à vous deux, je vais tester vos pistes, si je trouve le temps (et la motivation ) je ferais un bench des différente solution.
C'est pour du web donc je penses qu'on est sur sur MariaDB...