Re: [fr-users] [Base] Requête SQL de comptage

Bonjour,

Pour voir j'ai pris la base exemple et je me suis amusé à exécuter la requête de base qui 
permettrait d'obtenir les données que vous cherchez, à savoir 

SELECT "nom", COUNT( * ) AS "Nb" FROM "absencesCsV2" GROUP BY "nom";

J'obtiens la listes des noms, mais sans regroupement aucun, chacun est mentionné autant de fois 
qu'il figure dans la table de base.

Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf erreur c'est un problème lié à la 
version de HSQLDB, antédiluvienne. De là, il semble assez ambitieux de compliquer la chose pour 
demander à Base de fournir en plus par exemple la date de l'absence la plus récente…

Pour vérifier au cas-où, j’ai créé une table « absences" sur mon serveur Postgres, et l’ai 
alimentée avec les données fournies. Si on exécute la requête ci-dessus (en fait sous cette forme : 
SELECT nom, count(*) FROM absences GROUP BY nom;)  on obtient bien le nombre d’absences par 
personne, comme il se doit.

Donc, on retombe toujours sur ce suivi des problèmes dans l’environnement LibreOffice. Si HSQLDB 
est un choix compréhensible dans le contexte des débuts, figer le moteur dans cette version 
archaïque est une décision hautement critiquable. Vouloir palier à ses insuffisances en passant à 
un autre moteur était compréhensible, mais Firebird est d’un autre calibre et me semble sortir de 
la cible bureautique. En clair, il est trop gros, trop pro pour la cible visée.

Bref. N’est-il pas possible de fournir une version compatible SQL « normal » du moteur HSQLDB de 
Base, quitte à re-figer la situation pour les dix prochaines années ? Si je regarde la 
documentation de la version actuelle de HSQLDB, il semble que tout y soit pour gérer une base de 
données capable d’aider la gestion de très petites entreprises ou d’artisans. 

Il faut bien comprendre que structurer les données de gestion d’une entreprise sous la forme de 
tables normalisées est une approche très efficace, éprouvée. Ce n’est pas forcément dans le cloud, 
et tant mieux, car ainsi on ne dépend pas du réseau externe, on peut saisir ses factures le soir 
après l’activité sans redouter une coupure. 

Donc voir un moteur de base de données relationnelle dans une suite bureautique est une excellente 
proposition. L’état actuel de Base dans LibreOffice est paradoxal, car d’un côté on dispose de tout 
ce qu’il faut pour créer facilement des formulaires (saisie/consultation) et des rapports, de 
vérifier l’intégrité référentielle des données, mais on achoppe sur des trucs aussi basiques que 
cette syntaxe SQL défaillante, incomplète. C’est rageant.

Note en passant : Les données fournies devraient être nettoyées. Stocker une date sous la forme « 
Le 09/12/20 » est une hérésie, le « Le » n’a rien à faire avec la choucroute et il empêchera une 
reprise « intelligente » de ces données pour les traiter comme des dates exploitables. En bref, il 
faut distinguer le fond de la forme, la donnée proprement dite de sa présentation. Une fois que la 
donnée est stockée proprement, on peut en faire ce qu’on veut en lui appliquant des directives de 
formatage.

Sur ce, je passe la main aux gens compétents, jeunes et fringants de préférence !

Amicalement,

Thierry, Homme de Gros-Mignon




Le 20/10/2020 à 10:59, Stéphane Santon a écrit :

> Le 20/10/2020 à 10:39, Stéphane Santon a écrit : 
> > Base jointe. 
>
> https://www.cjoint.com/c/JJui607T1Un <https://www.cjoint.com/c/JJui607T1Un> 
>
> > (j'ai renommé ma colonne 'id' par 'nom') 

-- 
Envoyez un mail à users+unsubscribe@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy