Organisation de données - Page 1

yop,

Je cherche à modéliser un stock de pièces, et j'aimerais votre avis.

Voici de quoi compose un stock :
- un certain nombre de classes
- chaque classe comprend un certain nombre de sous-classes
- chaque sous-classe comprend un certain nombre de pièces référencées, dont l'entrée en stock est datée

Concrètement, il s'agit donc d'un arbre à trois niveaux, donc pas de souci pour le représenter avec de simples listes.

J'ai besoin de ces données essentiellement pour deux choses :
- connaitre l'état du stock maintenant
- faire un diff du stock entre deux moment quelconques

Et là, je me rends compte qu'il y a une autre manière de représenter les choses : une façon chronologique, et donc très linéaire dans la représentation des données.

Alors, les +/- des deux méthodes :
- je vais devoir parcourir l'intégralité de l'arbre pour avoir un stock à une date donnée, alors que ça serait super rapide avec une représentation chronologique
- la représentation sous forme d'arbre correspondant à la réalité de mon stock, elle sera ultra-rapide à charger (proportionnelle à la taille du stock), tandis qu'une représentation chronologique demandera toujours plus de temps avec le temps qui passe (proportionnelle avec les mouvements de l'historique)
- avec une représentation chronologique, pour connaitre le stock à une date aléatoire, il faut recalculer tous les mouvements depuis l'origine du stock. Charmant.
- pour une représentation en arbre, il va falloir parcourir l'historique de chaque élément dans l'arbre. Excitant


Ma question : quel sont les formats de données existants pour s'occuper de ce genre de cas ? C'est sûrement étudié sous toutes les coutures, de la gestion de stock il y en a partout.
Existe-t-il des outils, pour faire tout le boulot de calcul quand on veut accéder aux données à une date ou à une autre ?
Une solution qui me masquerait la représentation en mémoire pour ne me fournir que des fonctions de haut niveau serait la bienvenue.

Si ça n'existe pas ou que c'est trop complexe, ça ne me dérange pas non plus d'écrire mon format de données, pour peu qu'on m'aiguille vers la direction qui restera la plus performante dans le temps


Merci beaucoup.

Finalement, un stock, ça ressemble furieusement à un dépôt de sources. Comment font-ils pour être aussi performants ??

Tu réinventes une base de données, en somme ?

Je connais (très) peu le sujet, mais je pense que n'importe quel moteur de BDD doit te permettre de faire ça sans te prendre la tête, il doit juste falloir organiser tes données correctement et apprendre quelques commandes. À ta place, je me documenterais sur les fondamentaux des BDD

Ah, ben comme je viens de dire à Lionel à l'instant sur IRC, il me semblait bien qu'on me parlerait de ça.
Et comme tu le pressens, je n'y connais strictement rien.
Bon, ben on va regarder du côté de SQL (totalement au pif, bien sûr).

Par contre, le sus-cité Lionel m'a refilé les termes "Inventory management software" à googler, et il en sort des choses intéressantes.

C'est pour ton boulot ? Dans ce cas, évite de réinventer la roue, même si je sais que ça peut être tentant ^^

Pareil, je pense que sqlite est la solution la plus adaptée.

Cool. SQLite permet d'utiliser une bdd locale sous forme d'un simple fichier : je ne peux rêver de qqchose de plus simple.

Par contre, la bibliothèque semble être en C, je vais coder en C++. J'ai jamais interfacé ces deux langages, je suppose que c'est faisable aisément. A moins que SDLite 3 ait des bindings pour le C++.

Bon ben merci beaucoup, mais ce n'est qu'une partie de la réponse. L'autre partie est la réponse à "comment représenter les données dont j'ai parlé dans une bdd" ?

Bref, le problème est quasi-entier, mais j'ai déjà de quoi travailler, merci encore

Il y a d'un côté SQLite++, de l'autre des interfaces de plus haut niveau (QtSQL, SQLite ODBC, …). Mais on peut évidemment aussi utiliser l'API C directement en C++, c'est juste qu'il faudra alors reprendre les réflexes du C plutôt que ceux du C++ (genre l'appel explicit d'une fonction "free" plutôt que le RAII), même si on code en C++.

quelque chose de simple et brutal devrait fonctionner. Vois ta table « pièces » comme un tableau excel dont chaque ligne est une pièce en stock, et avec quatre colonnes : la première correspond au type de pièce, la seconde la date d'entrée en stock, la troisième la date de sortie de stock et la quatrième la raison de la sortie.

Pour connaître l'état du stock à une date donnée, il faut donc compter le nombre de pièce dont la date de sortie est nulle ou après la date choisie et la date d'entrée est avant la date choisie.
En SQL, ça se fait bien

@Kevin -> je pense tout simplement utiliser l'API C en C++, je veux rester aussi simple que possible !

@Flanker -> Je sais même pas ce que c'est que le concept de table dans une bdd. Je me représente ça comme une matrice, mais c'est probablement bien autre chose.

Ensuite, j'ai aussi une notion de classe et de sous-classe auxquelles appartiennent mes pièces, du coup est-ce que ce sont de simples colonnes en plus ?
Mais alors, comment "extraire", "connaitre" l'existence de ses classes et de ses sous-classes si mes données sont avant tout des "pièces" ? Et comment représenter une classe vide ?

Bref, vous m'avez indiqué l'outil à utiliser pour mes besoins (et oui, c'est pour le boulot), je ne peux plus avancer sans lire dessus. un grand merci pour toutes vos réponses !

C'est pour ton boulot ?

Si c'est le cas, indépendamment de mes sentiments personnels envers le dév web, je te conseillerais quand même de le faire sous forme d'appli web plutôt que d'appli en C++ :
- c'est plus facile à gérer si tu dois avoir plusieurs utilisateurs simultanés
- tu supprimes les problèmes de déploiement (vu que ça tourne sur le serveur, tout le monde utilise toujours la version la plus récente)
- ça facilitera la reprise du projet par quelqu'un d'autre dans l'avenir, si tu changes de boîte ou que tu as d'autres chats à fouetter
- c'est une compétence qui fera bien sur ton CV

Et puis c'est l'occasion rêvée d'apprendre le Python !

Folco (./9) :
@Flanker -> Je sais même pas ce que c'est que le concept de table dans une bdd. Je me représente ça comme une matrice, mais c'est probablement bien autre chose.

Pense à un tableau Excel dont tu aurais spécifié les colonnes à sa création (une bonne fois pour toute), avec des commandes pour ajouter, sélectionner, compter ou supprimer des lignes. Naturellement, tu peux avoir plusieurs tables en même temps, et faire des requêtes qui utilisent dans plusieurs tables.

Ah, je croyais avoir répondu à cette question. Donc :
- oui, c'est pour mon boulot
- c'est pour un utilisateur unique
- je développe ça sur mon temps perso, limité comme pour tout un chacun, je veux bien apprendre les rudiments des bdd, mais pas des nouveaux langages/frameworks. Vu que je connais déjà Qt et le C++, ça fait qu'il ne me reste que SQLite à apprendre. C'est jouable. Devoir apprendre plusieurs langages et technos, ça serait un plaisir évidemment mais c'est pas envisageable dans mon cas
- j'aurais probablement jamais les droits pour installer un serveur d'appli sur le serveur de la boite. Par contre, je peux y mettre des fichiers sans souci
- je compte bien monnayer mon travail, directement ou non (augmentation ou faire valoir sur le CV), donc c'est pas grave si personne ne peut reprendre derrière, bien au contraire. Et pas de chance si ça casse le lendemain de mon départ, j'y serai pour rien vu que je serai plus là.

OK

Ce que je ne comprends pas trop, c'est pourquoi, si tu utilises de toute façon Qt, tu n'utilises pas aussi QtSql avec son pilote SQLite plutôt que SQLite directement.

Je verrai. Je n'ai rien utilisé encore pour le moment, je suis en train de lire ça : http://www.tutorialspoint.com/sqlite/
Donc pour l'implémentation, je ne sais pas encore vers quoi je vais me diriger, mais j'ai quand même l'impression qu'il faut que je comprenne ce qu'est une table, un champs et une entrée avant de commencer à coder quoi que ce soit.

et hop, admirez cette discrète démonstration de l'adage bien connu : la science c'est comme la confiture, moins on en a plus on l'étale. Et là, je peux vous dire que j'étale sévère

edit -> rah les connards, ils ont réussi à glisser David Kim dans le tuto !!! http://www.tutorialspoint.com/sqlite/sqlite_commands.htm

Autant Ballmer j'aurais compris autant Allen je vois pas mais bon c'est ton choix

Kevin -> peux-tu me dire l'avantage d'utiliser l'API Qt à la place de l'API SQLite directement ? Ca ne me semble être qu'un wrapper à première vue, est-ce que ça apporte réellement quelque chose ?

si tu veux suivre un historique du stock, il te faut créer un ligne par item, et non pas seulement une ligne par référence (dans l'hypothèse où tu as plusieurs fois la même référence dans le stock)

Yup, je me suis posé la question, mais est-ce vraiment obligatoire ?
L'historique demande la suite chronologique des opérations sur les items d'une référence donnée, quel est le problème à avoir plusieurs ajouts ou suppressions pour un produit ?

Enfin, même si c'est accessoire, je vais afficher par référence, donc ça m'évite du boulot de stocker par référence et non par item. Mais ok, c'est accessoire.

Mais peut-être est-ce que je rate un problème auquel tu penses, dans ce cas je veux bien que tu m'expliques stp, merci d'avance.

Folco (./21) :
Yup, je me suis posé la question, mais est-ce vraiment obligatoire ?
L'historique demande la suite chronologique des opérations sur les items d'une référence donnée, quel est le problème à avoir plusieurs ajouts ou suppressions pour un produit ?

Enfin, même si c'est accessoire, je vais afficher par référence, donc ça m'évite du boulot de stocker par référence et non par item. Mais ok, c'est accessoire.

Mais peut-être est-ce que je rate un problème auquel tu penses, dans ce cas je veux bien que tu m'expliques stp, merci d'avance.

Comment fais-tu pour stocker plusieurs dates pour chaque opération entrée/sortie si tu as une seule colonne « date d'entrée » et une seule colonne « date de sortie » ?
Alors que si tu as une ligne par objet, c'est normal d'avoir seulement deux dates.

Je pensais avoir une liste d'opérations à côté, et faire le lien avec la liste des objets en stock. Mais c'est infiniment plus simple et pas forcément plus gros de faire comme vous proposez. Merci beaucoup !

Folco (./19) :
Kevin -> peux-tu me dire l'avantage d'utiliser l'API Qt à la place de l'API SQLite directement ? Ca ne me semble être qu'un wrapper à première vue, est-ce que ça apporte réellement quelque chose ?

C'est plus simple d'utilisation et ça facilite aussi le passage à une autre base de données si besoin.

flanker (./22) :
Comment fais-tu pour stocker plusieurs dates pour chaque opération entrée/sortie si tu as une seule colonne « date d'entrée » et une seule colonne « date de sortie » ? Alors que si tu as une ligne par objet, c'est normal d'avoir seulement deux dates.

Je reviens là-dessus, parce qu'il y a quelque chose qui me chagrine.
Ta question initiale du "comment je fais", ça peut se résoudre de différentes manières, avec par exemple une table chronologique des mouvements, référençant les opérations d'ajouts, modifications et suppressions, chacune d'elle liée à une référence.

Par contre, et je ne vous l'ai pas dit, mais les objets d'une même référence n'ont pas de numéro de série. Concrètement, si chaque objet va avoir effectivement une date de début et de fin, je ne sais absolument pas quand est rentrée une pièce que je sors.
Mes entrées vont donc avoir un couple entrée/sortie complètement fantaisiste (suivant que je décide de travailler en fifo ou en filo, par exemple).

Alors pour mesurer une quantité de matériel à un instant T, je ne crois pas que ça gêne (j'ai beau retourner le truc dans ma tête depuis des heures, je crois que ça n'a aucune incidence, mais n'hésiter pas à me contredire parce que c'est évidemment très important !)
Par contre, si je voulais mesurer une évolution dans le temps, en prix du stock ou en nombre de pièces, là ça renverrait des résultats complètement bidons.
Est-ce que vous voyez le problème ou ne suis-je pas assez clair ?

Même si a priori, j'ai pas besoin de faire de tels calculs dans le temps, ça me gêne de partir sur une représentation temporelle qui n'est qu'à moitié vraie. Non par perfectionnisme, mais parce que ça pourrait me limiter, par exemple.

Folco (./25) :
Ta question initiale du "comment je fais", ça peut se résoudre de différentes manières, avec par exemple une table chronologique des mouvements, référençant les opérations d'ajouts, modifications et suppressions, chacune d'elle liée à une référence.

En matière de modélisation de base de données, le problème qui est soulevé ici fait référence aux formes normales.

En théorie, tu as raison : dans une BDD, on ne doit normalement avoir une information qu'une et une seule fois. Typiquement, dans ton cas, tu devrais avoir une table de références, et une tables d'E/S avec ta référence.

Table 1 - Référence
Code interne (que tu peux avoir deux fois : un code interne à la BDD, plus une référence métier)
Code objet fournisseur
Code fournisseur
Libellé court
Libellé long
Description
...

Table 2 - Mouvements de stock
Code interne
Numéro de série
Date d'entrée
Date de sortie
...

Si tu avais tout dans une seule table, tu reproduirais de façon inutile tout un tas de données (le code fournisseur, les libellés, la description...).

Dans la pratique, il y a tout un tas de situations où on ne le fait pas. Tout va dépendre du nombre d'occurrences de la chose répété et de l'utilisabilité.
Dans le cas présent, je ne vois pas ce qui pourrait défendre la solution de la table unique (sauf si tu n'as que très peu d'informations redondantes, mais en général, même s'il y en a peu au début, il y a toujours du monde pour vouloir en rajouter au fil du temps), sauf éventuellement à ne pas partir sur une base de données mais un tableau Excel (où les données peuvent être plus difficiles à manipuler lorsqu'elles proviennent de deux feuilles différentes).

Mais tu vas forcément te retrouver avec des situations où on fera le choix d'avoir de la donnée redondante, parce que ce sera plus simple à maintenir (ou parce que la structure de données pré-existante ne te permettra pas de le faire, ou encore parce qu'on t'aura mal expliqué à quoi ça correspond ).

nilatoudi.

il faut surtout éviter de dupliquer des infos quand c'est pas la peine.

parfois y'a des cas ou il faut, et encore on peut parfois faire autrement.

(exemple: vente de tickets de spectacle ou tu veux garder l'historique a long terme des achats mais des spectacles finissent par devenir indisponibles. si tu dupliques pas l'info 'titre du spectacle' (par ex.) dans les historiques de vente, tu vas devoir te trainer TOUS les vieux spectacles plus vendus dans une table, juste pour afficher les historiques d'achats.)

Ce que vous dites est intéressant et je vous en remercie, mais ma question du moment est : est-ce tolérable d'enregistrer des infos erronées, qui certes vont me donner les bons résultats pour les besoins du moment, mais qui se révéleraient fausses dans le cas d'utilisations plus poussées ?

Ah oui, je suis passé à côté de cette information.
Tout dépend de ce que tu veux faire, mais vu ce que tu décris, voilà la structure que je donnerais à mes données :

Table 1 - Référence
Code interne (que tu peux avoir deux fois : un code interne à la BDD, plus une référence métier)
Code objet fournisseur
Code fournisseur
Libellé court
Libellé long
Description
...

Table 2 - Entrées/sorties
Code interne
Date
Opération (de type EVAL : ENTREE;SORTIE)
Quantité

Pour la structure de la base, je verrais bien une structure en trois tables :

• Classe
  • Nom
  • Description
  • Code interne
    ...
• Sous-classe
  • Nom
  • Description
  • Code interne
  • Code interne de la classe
    ...
• Opération
  • Code interne
  • Code interne de la sous-classe
  • Description
  • Date
  • Différentiel du nombre de produits
    ...

Lorsque l'opération consiste à ajouter des produits à ton stock, le différentiel du nombre de produits est positif, sinon, il est négatif. Pour avoir l'état du stock à une date, tu fais la somme des différentiels de toutes les opérations avant la date.
Pour éviter les redondances sur les opérations, tu pourrais ajouter une table Type d'opération dont tu renseignerais la clé unique des enregistrements dans ceux de la table Opération.