Discussion :

[Cisman]

Bonjour à tous,

j'essaie de faire un travail sur la gestion d'élève d'une école ou je dois pouvoir ajouter un étudiant, en archiver, afficher les étudiants d'une section soit par ordre alphabétique, par ordre de résultats, afficher les échecs. Pouvoir changer un étudiant de section, encoder et calculer ses résultats. le tout sera enregistré dans des fichiers binaire et je dois pouvoir récupérer les infos dans ces fichiers binaire et enregistrer les modifications dans ces fichiers binaire à la sortie du programme.

Je suis partit par facilité mais surtout pour leur flexibilité, sur des listes chainées.

Je sais qu' il y a moyen de travailler avec un index par étudiant qui servirait pour le tri, rechercher un étudiant, etc...
ces index seraient repris dans un tableau, éviterait de devoir charger à chaque lancement de programme tout le fichier binaire dans une liste chainée, mais juste travailler sur base de ces indexes. Le problème, je ne vois pas du tout, comment faire le lien entre les deux.

Je maitrise toutes les notions, (tableau, listes chainée, fichier etc), mais je bloc sur ce système d'indexation. Si quelq'un pouvait me mettre sur les rails?

[dinobogan]

Si c'est un besoin réel, laisse tomber les fichiers "binaires". Une vraie base de données sera incroyablement plus efficace pour gérer tout sans soucis, faire des modifications, des extractions...
Tu peux utiliser MySQL. Tout sera placé dans des tables. Des notions de bases en langage SQL seront suffisantes.
Maintenant, si c'est un exercice, combien d'élèves auras-tu à gérer ? Il serait plus facile de tout monter en RAM (si ce n'est pas trop volumineux) puis de travailler avec le tableau complet.
Précise ton besoin, les limitations techniques et fonctionnelles.

[Cisman]

Ce n'est pas pour un besoin réel.
Pour un travail de fin d'année.
J'ai eu des cours sur postgre sql, mais les cours de C et SGBD étaient séparés.
En fait le but du prof c'est de nous faire travailler les notions vues pendant l'année, c'est pour ça les fichiers binaire.
Mon programme doit pouvoir gérer de petites comme de grosses écoles c'est pour ça que je pensais à un index, si l'école compte 2000 élèves ça commence à faire lourd dans la RAM.

[leresidue]

Vous pourriez faire un tableau de pointeurs vers les éléments de vos listes chaînés. Et faire un tableau de pointeurs vers vos tableaux. Par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
struct tableauliste {
      ELEVE      *eleves;
      size_t       nbelevesdanstableau, taillemax;
};
 
struct tableautab {
      tableauliste      *tabs;
      size_t              nbtabsdanstableau, taillemax;
};

Mais c'est peut-être un peu compliqué. Mais ça sera possible d'utiliser des indexs pour accéder les différents éléments eleves ou tabs.

[dinobogan]

Mon programme doit pouvoir gérer de petites comme de grosses écoles c'est pour ça que je pensais à un index, si l'école compte 2000 élèves ça commence à faire lourd dans la RAM.

Non, ce n'est rien pour la RAM. Imaginons que chaque élève représente 1000 octets (et ça me semble déjà beaucoup pour nom, prénom, adresse, niveau d'étude, classe, spécialité...) alors un tableau de 2000 élèves utilisera 2 Mo, c'est à dire rien du tout sur un ordinateur "normal". Imaginons qu'un élève soit représenté par 100 Ko (ce qui deviendrait énorme, on peu ajouter une photo) alors 2000 élèves seront représentés en RAM par 200 Mo, ce qui est encore une fois très raisonnable.
Si le prof ne t'oblige pas à utiliser des index pour faire un chargement partiel, alors ne te casse pas la tête : tu as un tableau de structure "Eleve" que tu lis en une seule fois depuis un fichier et que tu flush en une seule fois pour la sauvegarde.

[Cisman]

Ok, je vais abandonner l'idée de l'index, c'est vrai que c'est se compliquer la tâche pour rien.
Merci.

[Sve@r]

Bonjour

Ok, je vais abandonner l'idée de l'index, c'est vrai que c'est se compliquer la tâche pour rien.

En fait, l'index a une utilité pour un fichier. Si par exemple tu as 3 étudiants dans ton fichier, avec 2000 caractères pour le premier, 5000 pour le second (photo etc), alors le 3° est placé à la position "8000" du fichier.
Si tu cherches le 3°, tu devras alors lire 8000 octets pour le trouver. Alors que si tu stockes dans un second fichier parallèle seulement le nom de l'étudiant et sa position dans le fichier, alors ce second fichier (bien plus petit) sera alors plus facile à parcourir.
Ainsi, en cherchant un étudiant par son nom, tu peux le retrouver rapidement dans le second fichier et avec sa position, aller directement dessus dans le premier fichier. C'est ça l'index.

Mais effectivement aller indexer une liste chainée...

[Cisman]

Merci pour les explications sur l'index.
Donc si je fais un second fichier avec juste le nom de l'étudiant et son ID, ID qui correspond à l'ID du premier fichier.
Que j'arrive a déterminer sa position (n) dans la liste, je dois pouvoir en me déplaçant de n position (structure) dans mon fichier binaire,
arriver à afficher par exemple les caractéristiques d'un seul étudiant.
Et donc ne charger qu'une seul structure dans la RAM plutôt que de charger toute une section.
Ça me parait quand même plus rapide et moins gourmand en ressources?

Votre avis?

[Sve@r]

Ça me parait quand même plus rapide et moins gourmand en ressources?

Moins gourmand, certes. Mais au regard de la réponse de dinogoban, écrire sur disque pour économiser 1Mo de RAM par groupes de 1000 élèves (avec une estimation de 1000 octets par élèves ce qui est assez enorme !!!)...
Quant à être plus rapide de lire un fichier (aussi petit soit-il) que des infos stockées en mémoire...

[Cisman]

Ok, donc Go pour tout charger dans la ram.
Merci pour vos avis éclairés

[Sve@r]

Ok, donc Go pour tout charger dans la ram.

Surtout que si tu adoptes la philosophie MVC (Modèle, Vue, Controleur) tu pourras alors changer facilement l'un pour l'autre si tu veux.

La philosophie MVC permet de détacher les 3 grandes catégories d'un logiciel. On a d'abord le Modèle (le stockage). Cette partie ne s'occupe que du stockage et de la restitution de données. Ensuite on a la Vue, qui ne gère que la partie saisie/affichage. Et enfin le Contrôleur s'occupe de calculer les nouvelles données à partir de données existantes.
Ainsi, en séparant dès le départ ces 3 groupes, on peut ensuite changer l'un sans toucher aux autres. Si aujourd'hui tu décides de stockere en RAM, mais que demain tu préfères utiliser un fichier, alors tu ne changeras que la partie dédiée au modèle...