Discussion :

[Lyche]

Bien le bonjour.
Alors voilà, ce sujet et je l'espère pas un déslestage, enfin j'espère que vous ne le considèrerais pas comme. Je vous expose les faits.
Je travail pour un assez gros groupe bancaire français (pas de pub ) et je me retrouve dans une situation un peu étrange. Je dois développer un outil de reporting pour permettre aux directeurs d'agences de consulter les données sous formes de graphiques. Pour le moment le développement n'en est pas là.
Afin de traiter les bonnes données je dois les récupérer d'un fichier (de 5 fichiers pour être précis) csv. Jusqu'ici tout vas bien. Malheureusement, je tombe sur une chose que je n'ai jamais vu jusqu'a présent, c'est une quantité incroyable de données et surtout, elles sont pas faites à la base sous un schéma relationnel de tables. Tout est stocké en masse à chaque nouvelle saisie, modification ou toute utilisation de la base (tous les calculs sont effectués en même temps et les résultats sont stockés dans la base afin de ne pas avoir à les faire à chaque consultation des données). Là, ça se complique . J'ai appris qu'ils avaient fait ça pour une question de "gestion des ressources du server" Simplement parce que les quantité de données traité par ce logiciel dépasse les 100Millions par semaines. Du coup, Je me pose des questions sur quelle option choisir.

- Faire un schéma relationnel de BDD classique, avec des tables indexées et des lisaisons entre les tables afin d'être structuré, tout en prenant en compte le fait que j'aurais pratiquement le même nombre de données dans ma BDD, (nombre qui risque de tripler d'ici fin juin avec la gestion futur de nouvelles données). Et un calcul des données (les pourcentages, les delta de stocks et autres)
- Adopter un schéma similaire au leur, que je n'ai jamais étudié ou vu jusqu'a présent durant ma courte carrière.

Je ne vous demande pas une réponse absolue, mais je voudrais votre avis sur les 2 façons de faire afin de pouvoir prendre une décision.

Je en sais pas si je me suis bien fais comprendre alors si vous avez des questions n'hésitez pas.
Si il y a une 3ème façon que je ne connais pas et qui semble mieux adapté, je suis preneur

Par avance, Merci
Cordialement
Lyche

[ddaime]

Salut !

L'utilisation des fichiers cvs sont souvent appelé des fichiers 'à plat' que l'on parcours ligne par ligne, c'est pourquoi les calculs sur les champs y sont stocker, cela fait gagner un peu de temps. Par contre, l'utilisation d'un SGBDR serait, à mon sens, une bien meilleure solution même avec la quantité de données énorme que vous avez à traiter puisque les bases de données (pas tous bien sur) sont optimisés pour traiter justement les gros volume et certains, comme SQL Server, intégre des outils de reporting trés performant. D'ailleur, c'est étonnant que vous n'utilisiez pas encore de SGBDR !

[Lyche]

En faite, le problème viens de l'entreprise qui à développé le logiciel. Ils sont parti, d'après ce que j'ai compris sur le system Datawarehouse, et en cours de développement ils ont changé, puis rechangé, etc.. pour finalement partir avec en laissant un logiciel tout buggué et que mon collègue de boulot répare depuis 1an. Je viens d'en parler avec mon patron il serait plutot lui aussi pour un SGBDR, mais je ne sais pas encore, puisque je n'ai qu'une ébauche du CDC, jusqu'a quand devront remonter les informations dans le temps, et cela va grandement influencer la quantité de données.
Je suis adèpte du SGBDR, mais je ne suis pas totalement fermé aux meilleurs moyens de gérer ça.
En ce qui concerne le système de SQL reporting, je ne sais absolument pas comment il fonctionne, et encore moins si je peux adapter ces résultats à une page développée en .Net c# pour consultation et pour faire un traitement automatisé qui créé des pdf afin que les directeurs d'agence s'en servent.
En tout cas merci pour ta réponse

[cavo789]

A priroi, rien ne devrait t'empêcher de charger les fichiers CSV dans une base de données; dans une ou plusieurs tables c-à-d que tu pourrais toi-même analyser les fichiers CSV pour en dessiner un schéma relationnel et créer ta DB sur base de ton analyse.

La création de la DB se fait manuellement; l'importation des fichiers via SSIS en SQL Server 2005.

Ceci fait, libre à toi de créer des views (càd des requêtes), des stored procedures voire des user defined functions ceci afin de supporter l'analyse que les directeurs des agences doivent faire.

Ensuite, dernière étape, venir mettre tout cela en musique soit dans un langage de programmation évolué et donc créer ta propre interface; soit en Excel (si si c'est possible) soit en utilisant SQL Server Reporting.

Comme tu vois, tu as encore beaucoup de lecture à faire et énormément d'apprentissage à réaliser avant de te lancer de ce très beau défi.

[ddaime]

Pour ce qui concerne les Reporting Services avec MS SQL Server 2005, il y à des tutos et des exemples sur le net et sur le site de Developpez.com. Il est bien sur tout a fait possible de créer de pages web en asp.net, utilisant le language C# et ADO.Net) afin de créer des rapports et de les imprimer au format PDF.

[Lyche]

Au niveau du langage, je suis un peu bridé, étant donnée que l'application est une application web développée sous VS2005 et c#2.0 que ma DB est SQL Server 2005.
En ce qui concerne le traitement des données, je récupère déjà les fichiers et je les stocks dans une table, cependant, la grosse question que je me pose c'est quel schéma de BDD je vais réaliser . Mon patron est plutôt contre un system DataWarehouse à cause des problèmes de l'autre logiciel. ddaime me dit que un SGBDR devrait être efficace, mais le fait qu'il y ai des centaines de millions d'enregistrement (je ne parle pas des lignes, mais de tous les types de données que comprennent les fichiers) sachant qu'il va y avoir une augmentation significative de ces données.
Une chose que j'oubliais de dire, je dois traiter ces informations en tache planifiée ou trigger, je sais pas encore, afin de stocker, traiter, créer les pdf, envoyer un mail à chaque utilisateur avec un lien vers le pdf le concernant et tout ça alors que je reçoit mes informations le lundi matin vers 9h-9h30 et je dois faire tout ça avant 12h.
Ma plus grosse peur est la quantité de données traitée dans le temps impartie.
Bref, ça paraît simple pour toutes les personnes qui bossent autour de moi, mais moi qui suis plongé dedans et qui ai des contraintes de temps d'exécution, je suis un poil moins réjouis qu'eux.
En ce qui concerne SQL Reporting Services, j'ai trouvé un bon tutoriel, mais je ferais une recherche sur dvp.com pour avoir plusieures sources (j'aime bien voir les différentes façons de faire.

Merci encore à vous.
Bien cordialement,
Lyche

[ddaime]

Au niveau du langage, je suis un peu bridé, étant donnée que l'application est une application web développée sous VS2005 et c#2.0 que ma DB est SQL Server 2005.

Bien au contraire puisque SQL Server 2005 s'intégre parfaitement avec Visual Studio 2005 donc aucun souci pour faire un appli web en asp.net et SQL Server 2005.
En ce qui concerne le volume de données que tu auras à traiter, je pense que le système Datawarehouse est justement fait pour ca, il y avait un exemple fourni avec VS2005 mais je ne sais plus le titre !

[Lyche]

Quand je disais bridé, c'est pas dans les possibilité, mais dans le choix de mon langage et de ma plateforme de dév. Je suis obligé de dvp sous VS/C# pour répondre aux demandes de la banque. Mais j'aime beaucoups VS et .Net en générale, ça ne me gène pas outre mesure.

[ddaime]

Au fait si ma mémoire est bonne, il y avait un exemple d'utilisation de Datawarehouse sous forme de webcast lors de la présentation de SQL Server 2005 avec un base de données contenant 1 millard d'enregistrement est ca 'marcher' du tonnère !

[cavo789]

Le nombre de records importe peu en SQL Server dès l'instant où tu as correctement dessiné ta db et que tu as mis des index là où il fallait.

Va lire les articles de SQLPro; ces derniers sont disponibles sur sqlpro.developpez.com

[SQLpro]

Il faudra cependant penser à bien dimensionner le serveur du SGBDR. En effet pour de grandes bases, le SGBDR peut être amené à utiliser des ressources très importante. Dans ton cas, le dimensionnement de la RAM va avoir une influence considérable. Vient ensuite le sous système disque. Il sera préférable de bien répartir les données sur différents agrégats RAID PHYSIQUE.
Enfin, suivant le nombre des utilisateurs pencher entre un quadri ou un octo processeur....

Donc attention entre l'adéquation des versions Windows et SQL pour la gestion de la RAM et du nombre de proc.

A +

[Lyche]

Merci pour toutes ces réponses, malheureusement, je ne travail que sur un server teste et seul ce que j'aurais fais de la base sera implanté, tout le reste, la mise en mémoire et la gestion des server de BDD me sont totalement hors d'accès. Mais bon, si les types qui s'en occupent sont là, j'ose espérer que ce n'est pas pour rien
Merci encore,
je vais consulter ton blog SQLpro pour plus d'informations.

Bien cordialement,
Lyche