Discussion :

[ilouma]

Bonjour tout le monde,
j'ai réellement besoin de votre aide, je dois faire la gestion d'une bibliotheque
et en ce qui concerne la recherche d'un livre elle doit etre multicritère, cad que je dois rechercher soit par code, par titre, par auteur ou par mot clé.
ce que je vois c des fonctions séparées, mais ca va etre lourd,
je preférerai intégrer tout ca dans une seule fonction, mais comme je suis débutant en pascal, je serai intéréssé par vos idées les amis
merci d'avance

[Loceka]

Tout dépend de la structure de donnée que tu utilises. Sans ça on ne peut pas te dire grand chose.

[bella82]

Tout est structuré sous forme de fichiers d'enregistrements.
je dois alors ouvrir mon fichier mais quels seront les critères a utiliser pour la recherche? un seul critère est suffisant pour effectuer la recheche. donc comment faire?

[Ultima]

Tout dépend de la structure de donnée que tu utilises. Sans ça on ne peut pas te dire grand chose.

+le préférable serait que tu utilise les enregistrements (record):

Par exemple:
livre1.auteur = 'La Fontaine'
livre1.titre = 'L' Amour et la Folie'
livre1.code = ...

Ensuite la bibliothèque pourait être un tableau:
Exemple:
Biblio = array [1..NbLivre] of T_Livre

Avec un bon codage, les fonctions seront faciles à écrire.

[Ultima]

Salut,
Montre comment sont codés tes enregistrements.

[ilouma]

je suis obligé d'utiliser des fichiers pour la gesion de la biblio
ca rentre dans le cadre de mon cours en pascal.

voila mon enregistrement livre

Code :

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

1
2
3
4
5
6
7
enreg_livre = record
    code : string[20];
    titre : string [20];
    auteur : string [10];
    editeur : string [10];
    resume : string [100];
end;

et voici le fichier livres :

Code :

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

t_livre = file of enreg_livre;

[droggo]

Kak,

Bonjour tout le monde,
j'ai réellement besoin de votre aide, je dois faire la gestion d'une bibliotheque
et en ce qui concerne la recherche d'un livre elle doit etre multicritère, cad que je dois rechercher soit par code, par titre, par auteur ou par mot clé.
ce que je vois c des fonctions séparées, mais ca va etre lourd,
je preférerai intégrer tout ca dans une seule fonction, mais comme je suis débutant en pascal, je serai intéréssé par vos idées les amis
merci d'avance

Plusieurs fonctions + 1 qui orientera ver l'une ou l'autre sera beaucoup moins lourd qu'une seule grosse fonction, meilleur moyen de faire un truc ingérable à terme.

D'autre part, il serait préférable de t'orienter vers une base de données plutôt que de faire tes propres fichiers avec ton format : cela assure une évolution beaucoup plus simple (car l'expérience montre qu'il y a toujours évolution de ce type de projet), et d'avoir des moyens de recherche dans la base très évolués.

[Loceka]

C'est pour un cours ou pour un travail en entreprise (ou projet personnel) ?

Si c'est pour un cours, le mieux c'est d'utiliser des record.

Sinon plutôt des bases de données ou des fichiers XML (sachant qu'il faudra les parser...).

Comme l'a dit Droggo, faire plusieurs fonctions de recherches interfacées par une seule fonction est moins lourd qu'en faire une seule grosse qui traite tout. Enfin ceci n'est pas vrai si tu utilises des bases de données vu que la seule chose qui changerais serait le nom du "champ" que tu passerais alors en paramètre (enfin si l'accès au BD en Pascal se fait comme en PHP ou en Java...).

[CapJack]

ca rentre dans le cadre de mon cours en pascal.

Sinon, il y aurait encore plus simple : utiliser un logiciel de gestion de fond documentaire, il en existe une foultitude !

Pour en revenir à la fonction, je ne suis pas d'accord sur le fait de déporter les différents critères de recherche dans des fonctions séparées, car celà interdirait une recherche multicritère (un auteur et un titre par ex.). C'est le reproche que le correcteur risque de faire, selon moi.

Je pense qu'il faut gérer les qatre critères de recherche simultanément dans la même fonction. Par ailleurs, penser que l'utilisateur peut aussi vouloir utiliser seulement un bout du nom ou du titre, etc.

[droggo]

Hao,

Sinon, il y aurait encore plus simple : utiliser un logiciel de gestion de fond documentaire, il en existe une foultitude !

Pour en revenir à la fonction, je ne suis pas d'accord sur le fait de déporter les différents critères de recherche dans des fonctions séparées, car celà interdirait une recherche multicritère (un auteur et un titre par ex.). C'est le reproche que le correcteur risque de faire, selon moi.

Je pense qu'il faut gérer les qatre critères de recherche simultanément dans la même fonction. Par ailleurs, penser que l'utilisateur peut aussi vouloir utiliser seulement un bout du nom ou du titre, etc.

Ça n'empêcherait rien du tout : pour l'exemple que tu donnes, on extrait toutes les oeuvres d'un auteur, puis on extrait le titre ad hoc avec les données fournies pour le titre.

C'est tout aussi rapide, et évite de se traîner une fonction trop longue avec des if ou case dans tous les sens, bref, une fonction typiquement dans le genre de ce qu'il faut éviter de faire.

Globalement, c'est un simple problème d'organisation logique du code.
Entre autres, écrire des fonctions avec des paramètres corrects qui fournissent une souplesse dans l'utilisation, avec au minimum que la recherche se fasse soit dans tout le fichier, soit dans une partie du fichier (par exemple, on peut extraire les données correspondant à un 1er critère dans un tableau [ou mieux, une liste] contenant les numéros des enregistrements [c'est suffisant, et évite d'utiliser trop de mémoire]).

[CapJack]

droggo, si j'ai proposé de n'écrire qu'une seule fonction, c'est dans le but de clarifier et de simplifier l'implémentation, parce qu'ainsi, on n'aura qu'une seule fonction, et une seule boucle, et que pour un projet scolaire, je ne suis pas bien certain que l'optimisation soit l'objectif premier.

En outre, avoir toutes les conditions alignées dans le même bloc de code me semble plus facile à comprendre et à corriger.



Maintenant, je vais te répondre de façon plus générale : premièrement, les deux façons de procéder sont strictement équivalentes sur le plan algorithmique.

Deuxièmement, sur le plan technique, imaginons un moment un très gros fichier, du genre qui ne tient pas en mémoire... tiens, imaginons que la base documentaire se trouve sur un serveur distant, avec une connexion lente.

Avec la méthode que je donne, on ne le parcourt qu'une seule fois sur une fonction complexe, avec des tests if et case, qui s'exécutent en mémoire.

Dans celle que tu soutiens, il faudra faire plusieurs passages à la suite sur le fichier, jusqu'à quatre passages, en procédant par élimination.

Plus performant ? Curieuse conclusion (assortie en outre d'une réflexion très désagréable, mais passons). Je veux bien qu'on n'aime pas les conditions, mais en faire un principe, que dis-je, LE principe, me paraît sérieusement extrémiste (et pas puriste, car qu'on le veuille ou non, les conditions font partie du langage).

En programmation comme dans beaucoup d'autres domaines, il n'y a pas qu'un seul point de vue, il n'y a jamais de solution unique et certainement pas de Vérité Absolue.

[droggo]

Jal,

CapJack : séparer en différentes fonctions n'est pas un moyen d'optimiser, mais de rendre le code plus facile à écrire/maintenir/modifier/lire...

Côté équivalence algorithmique, on s'en fout et contrefout : la première qualité d'un programme est de faire ce qu'il est censé faire, et la première qualité du code source de ce programme est d'être aisément maintenable/modifiable, y compris par un programmeur n'ayant pas participé à sa conception.
Si tu veux, il n'est pas difficile d'écrire un programme auquel tu ne comprendras rien, ou pas grand chose, et un autre qui fera la même chose et qui sera parfaitement clair dès la première lecture.
Lequel préféreras-tu utiliser si on te demande des modifications ?

Je n'ai jamais dit qu'il ne fallait pas utiliser de conditions dans un programme, par contre, je le répète et apparamment ne le dirais jamais assez : il faut toujours éviter de faire des fonctions trop longues, il faut les diviser en morceaux cohérents, ne serait-ce que pour la clarté du programme (on y revient, encore et toujours)

Côté rapidité, le traitement en un seul passage dans le fichier sera un peu plus rapide, je le sais bien, mais compte tenu du programme, ça n'ira pa bien loin, car il n'y aura pas des millions ou même milliers d'enregistrements dans le fichier (si c'était le cas, ne pas vouloir utiliser une vraie base de données est une grossière erreur).

Déjà, tel que c'est prévu, la structure ne convient absolument pas.
Pourquoi ?
Par exemple, pour chaque livre, on va stocker le nom de l'auteur, auteur qui par conséquent sera probablement référencé sous plusieurs orthographes (qui peut garantir qu'il n'y aura jamais d'erreur de saisie lors de l'utilisation d'un programme mérite d'être cité dans le livre des records, voire même de s'appeler dieu )

Et tes considérations sur un très gros fichier, ou l'utilisation d'une connexion lente n'ont rien à voir ici : je ne vois rien dans le problème qui suggère que cela puisse arriver.
- Côté connexion lente, n'y pensons même pas : si c'est vraiment lent, on ne pourra pas travailler avec un fichier de grande taille, même en une seule passe, le problème ne se pose même pas.
- Un fichier de très grande taille : voir plus haut.

Et enfin, je n'ai jamais prétendu avoir la vérité absolue, je ne fais que dire ce qu'est une démarche permettant d'écrire du code clair, donc aisément maintenable.
Le côté optimisation n'est nécessaire que dans certains cas : un programme qui met 2 secondes pour répondre au lieu de 1.1 seconde n'a jamais posé de problème à l'utilisateur (je ne dirais pas la même chose à choisir entre 1 ou 2 heures, ou même entre 1 ou 2 minutes)

Tout cela étant dit, si ça t'amuse, ce n'est pas mon problème.

[Alcatîz]

Bonjour !

Créer différentes fonctions permettant, sur un enregistrement chargé en mémoire, de tester chaque critère et appeler ces différentes fonctions au sein d'une fonction unique me paraît en effet être une saine manière de procéder, tout en assurant un découpage clair du code et une maintenabilité optimale.

Par contre, préconiser un traitement du fichier en plusieurs passes me semble tout bonnement aberrant.

[droggo]

Kam,

Alcatîz : tu as raison, aussi n'ai-je jamais dit que c'était LA solution, mais une possibilité.
Possibilité qui sans être optimum reste parfaitement applicable dans le cas d'un petit fichier, ce qui sera sans le moindre doute le cas de celui de ilouma, qui aura plus vite des problèmes d'homogénéité des données, comme je l'ai déjà signalé, que des problèmes de vitesse d'accès.

De toute manière, les fichiers personnalisés comme envisagé ne devraient plus être utilisés.

C'était une démarche justifiée tant que les gestionnaires de bases de données étaient rares et chers, ce qui n'est plus le cas désormais.

Il y a plusieurs solutions gratuites performantes, inutile je pense d'en faire la liste ici, même partielle.