Quelle structure de donn�es pour mon projet ?

Bonjour � tous,

Je vais tenter de concevoir un projet de gestion de stock en utilisant Qt. :lol:

S'appuyant sur des fichiers (pas de BDD), ce programme devra �tre capable de g�rer des informations :
- sur les fournisseurrs (noms, coordonn�es...) ;
- sur les articles de stock (noms, r�f�rences, quantit�s, dates, prix .....) ;
- sur les commandes en cours ;
Ajouts, suppressions, modifications, recherches et tris de ces �l�ments seront au menu ainsi que le traitements de certaines donn�es (totaux, moyennes ...).

Comment articuler et concevoir mes diff�rentes donn�es. Quelle type donner aux fournisseurs et/ou aux articles (structures, listes...) ? :roll:
Merci d'avance pour votre �clairage.

Salut,

Tu dois normalement voir ton probl�me sous trois axes principaux (et pas forc�ment dans l'ordre indiqu� :D):

La partie qui concerne la persistance des donn�es (le fait de pouvoir les r�cup�rer au d�part de ton / tes fichiers)
La partie qui concerne la gestion de tes donn�es (que se passe-t-il si je sors un produit du stock, ou si je rajoute un fournisseur ou une client :question:)
La partie qui concerne "l'ergonomie" de l'application et son interface.

Le premier axe cit� devrait te mener � envisager les donn�es que tu dois stocker comme s'il s'agissait d'une base de donn�es (d'ailleurs, c'est le cas, simplement, tu n'utilise pas forc�ment un syst�me de base de donn�es existant :D)

L'id�e est d'arriver � assurer une certaine coh�rence entre les donn�es (par exemple que l'adresse d'un fournisseur soit en relation avec... la commune o� il se trouve) tout en �vitant, autant que possible une trop forte redondance: il ne sert � rien, si un fournisseur fournit cinq produits diff�rents, d'avoir cinq fois son nom, son adresse, son num�ro de t�l�phone ou de compte bancaire.

De la m�me mani�re, il ne sert � rien d'avoir un produit connu sous plusieurs r�f�rences diff�rentes "simplement" parce que c'est un produit que tu peux te procurer aupr�s de plusieurs fournisseurs diff�rents ;)

Il t'appartient de d�cider du format dans lequel les donn�es sont stock�es (sous la forme d'un fichier "plat", du genre de CSV, ou plut�t sous une forme "XML like" :question:... Ou peut �tre sous une forme proche des fichiers ini de windows...) et de d�cider si tu cr�es un seul gros fichier qui contient l'ensemble des informations (comprend: les produits en stock, les fournisseurs, les clients et les factures) ou si tu travailles sur diff�rents fichiers pour chaque type d'information dont tu dois assurer la persistance.

Le cas �ch�ant, si plusieurs utilisateurs sont susceptibles d'utiliser l'application, mais que certains ne peuvent pas tout faire, tu devra �galement mettre au point un syst�me de permission et d'identification, qui devrait, id�alement, ne pas �tre �crit en dur dans le programme, mais qui se doit d'�tre suffisamment "s�curis�" pour �viter que n'importe qui n'aille acqu�rir des droits auxquels il ne peut pr�tendre.

Pense en outre au fait que plus tu arrivera � garder des responsabilit�s unique, plus les �volutions futures seront facilit�es.

Plut�t que d'avoir une "mega classe" repr�sentant une donn�e particuli�re capable de s'�crire et de se lire "toute seule" dans un fichier (selon le format que tu aura d�termin�), il est souvent int�ressant d'avoir trois classes bien distinctes:

La premi�re repr�sentant la donn�es particuli�re
La deuxi�me permettant d'�crire cette donn�e dans ton fichier
La troisi�me permettant... de lire cette donn�e au d�part du fichier

Lorsque tu abordera le deuxi�me axe de r�flection cit�, tu devra r�fl�chir aux r�gles qui r�gissent les diff�rentes interactions qui peuvent exister entre toutes tes donn�es.

Par exemple:

un produit ne peut, en tout �tat de cause, pas �tre pr�sent un nombre n�gatif de fois dans le stock
toute modification du stock doit provoquer, au minium � terme, une modification au niveau des fichiers
Certaines �tapes doivent �tre valid�es sous une forme "atomique" voire sous la forme d'une "transaction" (au sens BDD du terme: soit elles sont toutes valid�es, soit tout est d�fait)
la gestion des autorisations donn�es aux diff�rents utilisateurs, s'il �choit
...

Le dernier axe de r�flexion cit� portera sur l'IHM en elle-m�me:
Que fait on au travers de menu, au travers de bouton, ...
sous quelle forme repr�sente-t-on les diff�rentes donn�es
S'il �choit, quelle est l'ordre logique d'acc�s aux diff�rentes donn�es (il faut, peut �tre, passer par deux �tapes interm�diaires impos�es avant de pouvoir faire une chose particuli�re :question:)
mise en place d'un syst�me de discussion coh�rent entre l'application et l'utilisateur: l'utilisateur doit pouvoir donner des instructions, le syst�me doit pouvoir donner des informations sur la bonne prise en compte (ou non) de ces instructions
...
Ce dernier axe devrait s'appuyer sur le deuxi�me axe cit� afin de provoquer les changements au niveau... du premier

Fais attention au fait que l'efficacit� d'une application sera bien souvent bien plus importante si tu atteint un niveau d'ergonomie important:

Les utilisateurs se foutent le plus souvent pas mal de la machinerie qui est derri�re l'IHM qu'ils utilisent, mais r�lent tr�s facilement (et quelque part avec raison) si, pour acc�der � une donn�e particuli�re, ils doivent passer par cinq ou six �crans diff�rents ;)

Il est d'ailleurs important de travailler en accord avec l'utilisateur final, afin de prendre autant que possible ses habitudes de travail en compte (ce qui n'emp�che nullement d'essayer de l'inciter � "optimiser" sa mani�re de travailler) ;)

Ces trois axes de r�flexion entrent dans ce que l'on appelle l'idiome "model view controller".

Maintenant, tu nous demande quelle structure utiliser pour les diff�rentes donn�es que tu va devoir g�rer, mais l�, nous ne pouvons pas vraiment t'aider... � moins de prendre � notre compte l'int�gralit� du d�veloppement de l'application, ou peu s'en faut.

Il faut bien que tu justifie un tout petit peu ton salaire :D

Par contre, si tu veux un avis �clair� sur une partie du travail que tu auras fait, que ce soit au niveau de la conception ou au niveau de la mise en oeuvre, ou si tu rencontre un probl�me un peu plus pr�cis que "je dois cr�er une application de gestion", n'h�site pas � venir nous demander de l'aide :D

Citation:

Envoy� par stallaf

S'appuyant sur des fichiers (pas de BDD), ce programme devra �tre capable de g�rer des informations :

Pourquoi ne pas embarquer un moteur de type SQLite pour g�rer �a ?? Tu auras tes fichiers, pas de SGBD � installer, et au moins, tu pourras r�fl�chir � un niveau un peu plus efficace que la structure interne des fichiers...

Penses aussi � l'avenir : si ta bo�te se d�veloppe un peu trop vite, ton syst�me bas� sur les fichiers "bruts de fonderie" va vite r�v�ler ses limites, et le co�t de refonte sera bien plus important qu'en utilisant un moteur de BDD qui est, finalement, plus facilement rempla�able qu'une gestion bas niveau.

Citation:

Envoy� par Mac LAK

Pourquoi ne pas embarquer un moteur de type SQLite pour g�rer �a ?? Tu auras tes fichiers, pas de SGBD � installer, et au moins, tu pourras r�fl�chir � un niveau un peu plus efficace que la structure interne des fichiers...

Penses aussi � l'avenir : si ta bo�te se d�veloppe un peu trop vite, ton syst�me bas� sur les fichiers "bruts de fonderie" va vite r�v�ler ses limites, et le co�t de refonte sera bien plus important qu'en utilisant un moteur de BDD qui est, finalement, plus facilement rempla�able qu'une gestion bas niveau.

+1...

Et cela rend le besoin de clairement distinguer ce qui fait partie des diff�rents axes de r�flexion encore plus criant ;)

Bonjour, ;)

Apr�s une longue absence je reviens sur ce sujet et le projet associ�.
Je riens � remercier koala01 pour la qualit� de sa r�ponse et le temps qu'il m'a consacr�. Celle-ci a �t� lue avec beaucoup d'attention et j'ai suivi bon nombre de conseils prodigu�s par tous comme:
- authentification avec droits utilisateurs;
- fichier ini;
- utilisation d'une base de donn�es MySQL.
Comme c'est en forgeant... je rencontre quelques difficult�s que je n'arrive pas � r�gler seul.
Ceux-ci feront l'objet de nouveaux sujets.
Merci encore. :ccool: