Quel SGBD choisir ?

[Bourr1queT]

Actuellement, notre gestion des incidents se fait par une interface PHP/ fichiers CSV ... (en arrivant c'était comme çà, on pose pas de questions lol ) .
Je vais certainement être amené à réécrire çà pour des raisons techniques et évolutives.

actuellement ca tourne sur un ordi avec easy PHP . Vu que l'on est qu'une dizaine de personnes à attaquer les bases , y'avait pas besoin d'une usine à gaz.

J'en viens à mes questions..

- On doit gérer les incidents de 5 hopitaux . ( users, applis, techniciens )
- On va avoir environ 5000 enregistrement par mois. ( 1000 / hopital)
(donc + ou - 60 000 par an au total)


Quelle serait la meilleure solution ??

1 BDD par hopital / ou une BDD globale ?
1 BDD par hopital je trouve ca ch0, car beaucoup de données sont communes (applis, users, etc .. )


Ensuite , le probleme des mois.
- on enregistre tout à la file au fil des mois ... et ensuite bonjour les requetes ... ??
- on fait une table par mois ?

J'ai beau tourner le probleme dans tous les sens, je m'y perds un peu...

Vous auriez des idées ... ?

[Bob.Killer]

le BOT a posté !!!!, enocre du spam de merde...

pecky le pro de la bdd va te daire ça
_________________
Je m'appelle Inigo Montoya, tu as tué mon père, prépare toi à mourir !

[k0k0lap1]

Une seule BDD globale => MySQL

D'ailleurs sur marseille, ya mon collègue qui a regardé la dernière fois, notre système tourne en moyenne à 1600 requêtes par minutes. Donc 60 000 par an ca devrait allé

Sinon tu peux enregistrer tout dans une même base, en faisant un système d'achive, genre au bout d'un mois, t'envoies les enregistrements dans une autre table, une copie mais seulement pour les "archives".

Mais bon 60 000 enregistrements dans une table ca fera pas grand chose. On a eu un soucis ya pas longtemps chez vous, yavait il me semble 1,5 millions d'entrées dans une table
Ca lagait fortement, mais ca plantait pas.

[Bourr1queT]

[k0k0lap1]

T'aurais du écouter et apprendre tes cours à l'IUT

[Bourr1queT]

OH merci K0k0

donc une seule base, et en avant les enregistrements à la barbare. Non le truc c'est que pour faire des stats, on génère des graphiques en dynamique.

Par exemple en décembre, ta 60 00 enregistrements,il faut générer un graphique du mois d'avril, pour telle ou telle appli ...
Ca ne risquera pas de ramer alors ? Comme j'ai aucune idée du temps d'accès pour les requetes etc . Enfin si tu me dis que ca lag avec 1 millions d'engregistrement, ca devrait etre bon lol

[k0k0lap1]

Ben si tu as "seulement" 60 000 enregistrements par an, il n'y aura pas de problèmes.
Mais bon remarque si t'as envie de faire une table par mois ca peut se faire aussi, mais bon au bout d'un an t'auras les anciens encore dans la table.

Enfin je sais pas, je connais pas tout non plus tout truc. Mais pour moi ca me gène pas de placer toutes les opérations dans une seule table.
Et par exemple tout les ans tu places ca dans une nouvelle table où tu ne feras que de la consultation, et tu vides l'autre.

[Bourr1queT]

Le type avait une fichier CSV par mois et par année. A la limite une table portant le numéro de mois et lannee c'est ptetre pas trop mal non plus ...
Table qui serait créée automatiquement chaque début de mois..

[Bourr1queT]

En tout cas merci Pecky..

[Pecky]

[Bourr1queT]

Merci Peck pour ta réponse. En effet, tu as raison de souligner le statut des incidents.
On a plusieurs statuts : Pris en charge / en Pause / a cloturer / ouvers etc..
en fait techniquement parlant, j'ai pas mal de tables

user / hopitaux / applications / statuts / tehniciens / sévérité etc...

Le but de créer plein de tables différentes, c'est pour construire les menus déroulants en fonction de certaines tables, histoire d'être tranquille à l'avenir quand on rajoute ou retire des applis.


Le coup de verser les incidents dans une nouvelle table archive est une bonne idée, K0k0 m'avait soumis l'idée il me semble.

Merci beaucoup en tout cas, j'y vois déja + clair.