Poster une réponse à un sujet: [LAMP] Gestion/agégation et présentation de BCP de données.
Attention, ce sujet est un sujet ancien (4621 jours sans réponse)
blietaer
OVH>
Merci.
Pardon: Mirki, lol kikou!
![:love: :love:](images/smileys/love.gif)
Merci.
![:sol: :sol:](images/smileys/sol.gif)
Pardon: Mirki, lol kikou!
![:bisous: :bisous:](images/smileys/bisous.gif)
ovh
Il y a le fameux Jasper très connu. Sinon il y a aussi BIRT qui a l'air très intéressant (article ici : http://dsilvera.developpez.com/tutoriels/Business-Intelligence/utilisation-birt/)
Crytal Reports c'est hasbeen
Crytal Reports c'est hasbeen
![:tinostar: :tinostar:](images/smileys/tinostar.gif)
![:neowen: :neowen:](images/smileys/neowen.gif)
blietaer
Et sinon qqun a déjà joué avec des Reporting Tools opensource?
Genre le Crystal report c'est le pied?
Genre le Crystal report c'est le pied?
ovh
Honnêtement là je ne suis pas spécialiste, je ne saurais t'aider à faire le bon choix
![:cupra: :cupra:](images/smileys/cupra.gif)
blietaer
En effet, il y en a ici qui remettent en question la validité d'une DB pour des flat-files (teeeellement plus performants)
Je peux tout entendre, j'aime mieux avoir des chiffres.
Mais rien ne compteras plus que nos chiffres/benchmark..bref, y a du boulot.
![:kiki: :kiki:](images/smileys/kiki.gif)
Je peux tout entendre, j'aime mieux avoir des chiffres.
Mais rien ne compteras plus que nos chiffres/benchmark..bref, y a du boulot.
ovh
J'en avais presque oublié le sujet du projet
Dans ces cas-là une DB n'est ptêt pas la meilleure solution
Un bon p'tit prog en asm ?
![:tinostar: :tinostar:](images/smileys/tinostar.gif)
![:figti: :figti:](images/smileys/figti.gif)
Un bon p'tit prog en asm ?
![:petrus: :petrus:](images/smileys/petrus.gif)
![:neowen: :neowen:](images/smileys/neowen.gif)
blietaer
ové> héhé, quand on est pas gamer, on trouve d'autres justification pour faire du perf-p0rn !
gizmo> Bonne question et probablement bon point de départ: nos tables (de paquets) sont bien plus longue que large (une 20aine de champs en largeur: timestamp, signature, tos,...) mais en longueur...biggre, imagine que tu gardes une entrée pour chaque paquet vu sur le gateway d'une TRES grosse boite en ne gardant que le port 80,25,443 et 110. (c'est un exemple) Bref, VMT bcp.
![:itm: :itm:](images/smileys/itm.gif)
gizmo> Bonne question et probablement bon point de départ: nos tables (de paquets) sont bien plus longue que large (une 20aine de champs en largeur: timestamp, signature, tos,...) mais en longueur...biggre, imagine que tu gardes une entrée pour chaque paquet vu sur le gateway d'une TRES grosse boite en ne gardant que le port 80,25,443 et 110. (c'est un exemple) Bref, VMT bcp.
![:ohwell: :ohwell:](images/smileys/ohwell.gif)
gizmo
Euh, juste pour savoir, tu estimes à combiens d'insertion de records/heure active?
ovh
Tu veux prendre ton pied à configurer postgresql hein, avoue
![:petrusbranle: :petrusbranle:](images/smileys/branle2.gif)
blietaer
MySQL n'est pas dans la course (même après lecture de ton très bon comparatif)
Il s'agit uniquement de tunner-sa-mère à PostgreSQL.
Il s'agit uniquement de tunner-sa-mère à PostgreSQL.