[Base] Requête SQL de comptage

Bonjour,

Je cherche à créer une requête SQL sous Base qui me rajoute un champ "calculé", le calcul étant le nombre d'enregistrements qui ont un champ à la même valeur.

Depuis :

id | date_absence|
Larry | 05/09/2020 |
Sarah | 07/09/2020 |
Sarah | 12/09/2020 |
Sarah | 18/09/2020 |
Sarah | 01/10/2020 |
Anna | 25/09/2020 |
Anna | 27/09/2020 |
Anna | 05/10/2020 |
Henri | 21/09/2020 |
Henri | 25/09/2020 |

Je veux sortir ça :

id | date_absence| Qté |
Larry | 05/09/2020 | 1 |
Sarah | 07/09/2020 | 4 |
Sarah | 12/09/2020 | 4 |
Sarah | 18/09/2020 | 4 |
Sarah | 01/10/2020 | 4 |
Anna | 25/09/2020 | 3 |
Anna | 27/09/2020 | 3 |
Anna | 05/10/2020 | 3 |
Henri | 14/09/2020 | 2 |
Henri | 25/09/2020 | 2 |

Un truc du style

SELECT
  "Feuille1"."id" AS id_ref,
  "date_absence",
  (SELECT COUNT(*) FROM "Feuille1" WHERE "id" == "id_ref")
FROM "Feuille1"

Merci

Bonjour Stéphane,

Ceci pourrait marcher:

select id,
        date_absence,
        (select count(id)
         from presences as innerPresences
         where presences.id = innerPresences.id) as quantite
from presences;

Il s'agit d'une sous-requêtes corrélées: https://sqlpro.developpez.com/cours/sqlaz/sousrequetes/#L2

Bien à toi.

Bonjour,

Merci de l'aide. La colonne 'Qte' reste toujours vide.

Même avec un simple
SELECT
  "nom", "date_absence",
  ( SELECT COUNT( * ) FROM "absencesCsv2" ) "Qte"
FROM "absencesCsv2"

la colonne 'Qte' reste vide...

Base jointe.

(j'ai renommé ma colonne 'id' par 'nom')

Base jointe.

https://www.cjoint.com/c/JJui607T1Un

Bonjour,

Base jointe.

https://www.cjoint.com/c/JJui607T1Un

(j'ai renommé ma colonne 'id' par 'nom')

Il faudra ajouter un champ 'ID' numérique qui identifie les enregistrements de manière unique.

Bonne journée

Bonjour,

Base jointe.

https://www.cjoint.com/c/JJui607T1Un

(j'ai renommé ma colonne 'id' par 'nom')

Il faudra ajouter un champ 'ID' numérique qui identifie les enregistrements de manière unique.

Je comprends bien, mais il n'y a pas ça dans ma table de base qui est un export CSV.

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.

A notre que la fonction COUNT fonctionne parfaitement lorsqu’elle porte sur une requête plate (compter la cardinalité de l’ensemble renvoyé par une requête SELECT… WHERE).
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 (1.8), alors que la versions actuelle est 2.51.

On retombe sur les limites d’un système qui est maintenu du bout des lèvres. Ce qui est fort dommage, une base de données fonctionnelles étant un grand plus en matière de bureautique.

Il y aurait beaucoup à dire, mais comme je ne peux pas intervenir efficacement au-delà de la critique, je m’abstiens.

Bonne journée,

Thierry

Bonjour,

Merci pour ces essais et le retour d'information.

Je crois que pour 8 projets sur 10 un peu "avancés" (selon moi) que j'ai menés avec LibreOffice (au-delà des sentiers battus qui utilisent 3 styles et 1 champ), je me suis heurté à des bugs LibreOffice !!

Une fois de plus, je vais DEVOIR conduire une quinzaine de collègues à travailler sous MS Office ou peut-être GSuite Education, à mon grand désarroi.

Je repense encore à un fil de la liste d'il y a quelques semaines, où quelqu'un rouspétait contre la fuite en avant aux fonctionnalités avant de corriger les bugs.
Quand je vois la sortie d'une version "7" avec toutes les casseroles restantes, ça me met de mauvaise humeur.

Merci encore aux aides nombreuses et précieuses des membres de la liste, et des forums tiers qui sont très accessibles en moteurs de recherche.

Bonjour,

Base jointe.

https://www.cjoint.com/c/JJui607T1Un

(j'ai renommé ma colonne 'id' par 'nom')

Il faudra ajouter un champ 'ID' numérique qui identifie les enregistrements de manière unique.

Je comprends bien, mais il n'y a pas ça dans ma table de base qui est un export CSV.

L'instruction SQL pour faire la somme des absences attend plutôt une donnée numérique pour faire l'addiction.

La solution est donc de créer une (vraie) Base de données, de coller le csv dans cette Base pour créer une Table puis d’utiliser cette Table pour faire un Rapport.

Dans le Rapport, dans le Pied de page de Groupe, il faut insérer un champ Compteur qui va additionner le nombre de dates d'absence.

https://framadrop.org/lufi/r/PsYRdfrZpd#YKI/gNDYj1DQjuAxALexiFXXgHe5GDaF1kb+XRD16Ys=

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

J’exécute rarement des scripts d’origine étrangère sur mes machines.

Bonjour

Thierry Jeanneret wrote

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

Je réponds quand même...

Je tombe par hasard sur ce fil...

Thierry Jeanneret wrote

...
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 (1.8), alors que la
versions actuelle est 2.51.
...
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.
...
on achoppe sur des trucs aussi basiques que cette syntaxe SQL défaillante,
incomplète. C’est rageant.

Euh… tout ça ???

La base de données jointe est au format TEXTE et non hsqldb. Il est donc
normal de ne pas disposer des fonctions de groupe. Pour mémoire le format
est indiqué dans la barre d'état et dans Édition> Base de données> Type de
connexion.

On n'aurait pas non plus ces fonctionnalités avec un format classeur par
exemple.

Si on copie les données (+1 pour la remarque sur le contenu du champ
absences) dans une base hsqldb on a bien le résultat souhaité mais pas avec
ce qui est indiqué :

SELECT "nom", COUNT( "nom" ) "Nb" FROM "Table1" GROUP BY "nom"

Le résultat souhaité doit comprendre la date (même si on peut s'interroger
sur la pertinence du besoin).
Le résultat est obtenu avec une requête du type :

SELECT "nom", "date_absence", ( SELECT COUNT( "nom" ) FROM "Table1" "B"
WHERE "Table1"."nom" = "nom" ) "Nb" FROM "Table1"

Cela dit, puisque les données sont au format csv le plus simple serait de
faire ce traitement dans le tableur (sauf précisions manquantes).

Je vous laisse tirer vos conclusions...

Nouvelle_base_de_données.odb
<http://document-foundation-mail-archive.969070.n3.nabble.com/file/t246115/Nouvelle_base_de_données.odb>

Cordialement

Ce n'est un script, c'est une clé d'authentification de l'auteur du
message, si c'est de ça dont vous parlez.

Régis

C’est de ça. Ça s’envoie en public, ce truc-là ? J’y croyais pas...

Envoyé de mon iPhone

ben une clé publique a vocation à être publique, c'est un peu le
principe. Mais il faut une clé... privé, non diffusable pour la
déchiffrer... Si tant est que ce soit ça
de toute façon je doute que le message de David soit arrivé à beaucoup,
je ne l'ai pas reçu et je ne le vois pas dans les archives...
Uniquement dans les citations....
Claire

Bonjour Pierre-Yves et tous

merci pour ta réponse.
Je suis "de loin" ce fil car j'avoue que....

Bonjour

Thierry Jeanneret wrote
> Sur ce, je passe la main aux gens compétents, jeunes et fringants
> depréférence !

Je réponds quand même...
Je tombe par hasard sur ce fil...

Thierry Jeanneret wrote
> ...Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf
> erreur c'estun problème lié à la version de HSQLDB, antédiluvienne
> (1.8), alors que laversions actuelle est 2.51. ...on achoppe sur
> des trucs aussi basiques que cette syntaxe SQL
> défaillante,incomplète. C’est rageant.

j'ai effectivement été freinée dans mon usage de Base, à chaque fois
que j'ai voulu utiliser un peu de SQL...

Mais, comme tu le dis....

Euh… tout ça ???
La base de données jointe est au format TEXTE et non hsqldb. Il est
doncnormal de ne pas disposer des fonctions de groupe. Pour mémoire
le formatest indiqué dans la barre d'état et dans Édition> Base de
> Type deconnexion.
On n'aurait pas non plus ces fonctionnalités avec un format classeur
parexemple.

J'ai découvert trés récemment cette limitation qui est pourtant
parfaitement documentée. C'est trés simple de prendre du txt ou du csv,
du dbf pour en faire une base, mais les fonctionnalités sont de fait
plus limitées.
Est-ce qu'il existe (je n'ai pas cherché..) suffisament de doc pour
guider dans la conversion de base en format texte ou classeur vers
HSQLDB ? Est-ce que la doc Base 6.4 qui est en cours de traduction,
notamment par Jean Michel je crois, intègre cette info ?

@Thierry, pas d'accès concurrent avec Base à ma connaissance, ce qui
est aussi limitant. Ex : un formulaire de saisie (qui alimente la base
x) utilisable par 2 personnes en même temps...
Claire

Bonsoir,

Bonjour Pierre-Yves et tous

merci pour ta réponse.
Je suis "de loin" ce fil car j'avoue que....

Bonjour

Thierry Jeanneret wrote

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

Je réponds quand même...
Je tombe par hasard sur ce fil...

Thierry Jeanneret wrote

...Le GROUP BY est donc tout pourri et ne fonctionne pas. Sauf
erreur c'estun problème lié à la version de HSQLDB, antédiluvienne
(1.8), alors que laversions actuelle est 2.51. ...on achoppe sur
des trucs aussi basiques que cette syntaxe SQL
défaillante,incomplète. C’est rageant.

j'ai effectivement été freinée dans mon usage de Base, à chaque fois
que j'ai voulu utiliser un peu de SQL...

Mais, comme tu le dis....

Euh… tout ça ???
La base de données jointe est au format TEXTE et non hsqldb. Il est
doncnormal de ne pas disposer des fonctions de groupe. Pour mémoire
le formatest indiqué dans la barre d'état et dans Édition> Base de
> Type deconnexion.
On n'aurait pas non plus ces fonctionnalités avec un format classeur
parexemple.

J'ai découvert trés récemment cette limitation qui est pourtant
parfaitement documentée. C'est trés simple de prendre du txt ou du csv,
du dbf pour en faire une base, mais les fonctionnalités sont de fait
plus limitées.
Est-ce qu'il existe (je n'ai pas cherché..) suffisament de doc pour
guider dans la conversion de base en format texte ou classeur vers
HSQLDB ? Est-ce que la doc Base 6.4 qui est en cours de traduction,
notamment par Jean Michel je crois, intègre cette info ?

@Thierry, pas d'accès concurrent avec Base à ma connaissance, ce qui
est aussi limitant. Ex : un formulaire de saisie (qui alimente la base
x) utilisable par 2 personnes en même temps...
Claire

Soit dit en passant, il y a une solution très efficace et stable pour utiliser Base avec des requêtes SQL, c'est d'installer MySQL (ou MariaDB), un connecteur mysql (le connecteur jdbc marche très bien) et tout marche à merveille ! Evidemment, pas d'exportation possible, mais pour du publipostage c'est parfait.

Bonsoir,

Fil de discussion très instructif pour moi, le demandeur.

Hier soir j'ai trouvé sur un forum une requête avec COUNT(*)+1 qui fonctionne sur Base, et je me suis douté que la source CSV était la cause du mauvais résultat de HSQLDB 1.8.

J'ai essayé d'activer l'option "Avancé | fonctions expérimentales" en espérant faire tourner Firebird, mais sans succès.

Pour ce qui est de la date sous la forme "Le ...", c'est un peu simplifié mais c'est effectivement sous forme de texte.qu'est fournie la plage de dates.
Ceci vient d'un export CSV du logiciel de Vie scolaire "Pronote".
Je pourrais demander qu'ils incluent des champs supplémentaires un peu plus normalisés... pour une mise en place dans 18 mois.

Ma finalité, c'est que l'utilisateur.ice (un.e collègue) fasse le job en un minimum d'étapes :
- lancer l'export CSV Pronote et enregistrer le fichier CSV dans un dossier dédié,
- ouvrir un fichier Writer préparé pour le publipsotage lié au CSV,
- lancer les exports de publipostages individuels en PDF.

Re,

Pour en avoir le coeur net je viens de créer une table neuve, avec initialement deux colonnes : nom, date. Au cours de la création, HSQLDB exige une colonne d'index (normal en somme). Je l'ai donc laissé faire, en modifiant juste la propriété de la colonne ID créée en la mettant en incrément automatique.

J'ai alimenté cette table avec les requêtes suivantes, une légère extension du fichier .csv initial :

INSERT INTO "absences" ("nom", "date") VALUES ('Larry', 'Le 05/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 07/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 12/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 18/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Sarah', 'Le 01/10/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 25/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 27/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Anna', 'Le 05/10/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Henri', 'Le 21/09/20');
INSERT INTO "absences" ("nom", "date") VALUES ('Henri', 'Le 25/09/20');

A ce stade la table contient :

SELECT * FROM "absences"

2,Larry,Le 05/09/20,
3,Larry,Le 05/09/20,
4,Sarah,Le 07/09/20,
5,Sarah,Le 12/09/20,
6,Sarah,Le 18/09/20,
7,Sarah,Le 01/10/20,
8,Anna,Le 25/09/20,
9,Anna,Le 27/09/20,
10,Anna,Le 05/10/20,
11,Henri,Le 21/09/20,
12,Henri,Le 25/09/20,

Il y a deux "Larry" ensuite d'autres manipulations...

Manifestement, l'index doit lui plaire car j'obtiens ceci :

SELECT "nom", COUNT(*) FROM "absences" GROUP BY "nom";

Larry,2,Larry,
Sarah,4,Sarah,
Anna,3,Anna,
Henri,2,Henri,

Mais par contre, le format de sortie est incorrect, je ne vois pas pourquoi le nom est répété ni pourquoi il y a systématiquement une virgule en fin de ligne.

Si je modifie la requête ainsi :
SELECT "nom", COUNT(*) AS "cnt" FROM "absences" GROUP BY "nom";

J'obtiens ceci :

Larry,2,Larry,
Sarah,4,Sarah,
Anna,3,Anna,
Henri,2,Henri,

La renommage de la colonne COUNT(*) ne se fait pas, ce qui indique qu'il y a vraiment des trucs bizarres qui flottent dans le potage.

Bref, il semble qu'en créant une clé unique on parvienne à faire fonctionner partiellement les fonctions d'agrégation, mais franchement, je ne compterais pas trop dessus, d'autant plus si la sortie est choucroutée.

Peut-être qu'un jour, une nouvelle version, ou un autre moteur, qui sait... Moi, je m'arrête là pour ce sujet.

Ah, par contre si on veut connaître la date de la dernière absence de chaque élève, voici comment faire (ATTENTION, les DATES sont bien sûr traitées comme du TEXTE. D'où ma remarque précédente !) :

SELECT DISTINCT a."nom", a."date" FROM "absences" a  WHERE a."date" = SELECT MAX(b."date") FROM "absences" b WHERE a."nom" = b."nom";

Anna,Le 27/09/20,
Henri,Le 25/09/20,
Larry,Le 05/09/20,
Sarah,Le 18/09/20,

Il y a toujours des virgules en trop, mais bon.

Bonne fin de journée,

Thierry

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.

Normal, avec des tables texte, l'agrégation n'est pas possible. Mais la doc en français est (encore) inexistante, je suis en train de la traduire)

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…

Eh bien oui, c'est une erreur, et ce n'est pas lié à cette version, qui, bien qu'antédiluvienne, fonctionne parfaitement, et permet des requête bien plus complètes.

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.

Si on pouvait éviter ce genre de jugement à l'emporte pièces. Ce qui y est n'est pas bien, ce qui va le remplacer est trop gros, ...

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.

C'est tout à fait le cas actuellement.

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.

Voir ci- dessus. Dans de "bonnes" conditions, ça fonctionne.