Tu peux accumuler niaisement, tu as la date de chaque printout, indexée. Rien ne limite la fourchette de dates, ni au niveau des inserts, ni ailleurs. C'est à toi de requérir sur "date between xxx and yyy" si tu en as besoin. Côté volume, rien à craindre, SQLite assume.
Pour SNMP, je ne suis pas assez familier avec, donc je risque de te dire (encore) des couenneries. Au niveau du principe, tente d'extraire les infos sous le même format que celui des logs. Quite à rajouter une colonne "source" dans la table printout, qui pourrait valoir 'S' (SNMP), 'L' (logs), 'D' (divination), ...
Tu peux faire ce que tu veux avec un fichier Excel via l'UDF ... Excel. Facile.
Pour le total de copies par groupe, il faut savoir de quoi on parle :
select upper(groupname) as Groupe, total(pages * copies) as "Copies imprimées" from printouts natural join users natural join usersgroups natural join groups group by groupname order by groupname;
va bien renvoyer une liste de tous les groupes qui ont imprimé avec le total des copies faites
par ce groupe.
Mais ...
si un user fait partie de deux ou plusieurs groupes, son total de copies
► Afficher le texte
va apparaître dans chaque groupe où il figure
Il faut toujours bien réfléchir avant de se lancer dans le vide sans parachute sinon nos merveilleuses machines nous renvoient, à la vitesse de l'éclair, nos "myopies" dans les dents sous forme de données non significatives et de pseudo-informations faussées.
Exercice : modifier la requête précédente pour éviter cela, faisant donc en sorte que le total des copies attribuées aux différents groupes corresponde au total des copies physiques.
Quand tu as des requêtes récurrentes (type rapports), n'hésite pas à en faire des vues, par exemple :
► Afficher le texte
CREATE VIEW [Est_Membre_De] AS
select username "L'utilisateur", group_concat(groupname, ', ') "fait partie de" from users natural join usersgroups natural join groups group by userid order by username;
CREATE VIEW [Groupe_Comprend] AS
select groupname "Le groupe", group_concat(username, ', ') "a pour membres" from users natural join usersgroups natural join groups group by groupid order by groupname;
CREATE VIEW [Copies/Groupe] AS
select groupname as Groupe, total(pages * copies) as "Copies imprimées" from printouts natural join users natural left outer join (select * from usersgroups group by userid) natural join groups group by groupname order by groupname
Zut, j'ai bien peur d'avoir donné la solution...
Ensuite, dans ton appli, tu peux récupérer le contenu de la vue comme si c'était une table, à laquelle tu peux d'ailleurs rajouter des conditions de sélection :
► Afficher le texte
select * from [Copies/Groupe] where date like '2011-09';
Une vue ne coûte rien : ce n'est qu'une requête (celle qui définit la vue) stockée dans la DDL de la base. Elle ne s'exécute que lorsque tu l'affiche avec ton manager ou quand tu "tapes" dedans avec une autre requête, comme celle ci-dessus. Elle en devient alors une sous-requête. Cela simplifie/clarifie le code de ton appli. Qui plus est, il est possible de modifier les données d'une vue (si, si !) par des triggers INSTEAD OF qui permettent de modifier la ou les tables qui alimentent cette vue.
>Tu vois que les possibilités sont virtuellement infinies, avec _très_ peu de code en fait (une fois que le schéma de la base est créé). Imagine le code AutoIt qu'il te faudrait écrire si tu voulais obtenir autant de souplesse et de puissance de requêtes et les difficultés de mise au point et de maintenance/évolution.
Encore une fois, j'avoue profiter lâchement de ton exemple de projet pour illustrer à quel point SQLite s'avère l'outil idéal pour stocker, organiser et accéder à des données applicatives sous un format portable, compact et terriblement efficace. Quand on rajoute à ça les qualités
ACID que SQLite offre naturellement, on voit mal pourquoi certains s'obstinent à maintenir péniblement des usines à gaz de multiples fichiers aux formats propriétaires qui n'assurent aucune solidité et demandent beaucoup plus d'efforts de développement.