Bonjour,

Je me suis lancé il y a peu je me suis lancé dans un projet sur les séries temporelles avec un interpréteur qui traduit une requête de série temporelle.

En fait j'arrive plutôt bien a cerner le sujet mais pour la partie développement je suis encore dans le flou.

Le premier objectif c'est de stocker les données qu'on nous donne sous cette forme (C'est en fait des actions d'entreprise à l'ouverture et fermeture d'une journée) :  

Actions : 

J'ai trouvé la solution de stocker ces infos en 5 tableaux comme ci-dessous. ça va me permettre de pouvoir jouer avec les futurs demande de l'utilisateur.

Sièges sociales

-
Edité par Lord Petrus 7 février 2019 à 23:01:30

Heu, tous ses salamalecs pour une simple application qui peut être faites avec 4 pauvres tables SQL, un moteur de base de données avec le midleware ad hoc et un contrôles d'affichage de grille ?

Le genre d'application qui sert d'exemple de tutoriel d'initiation à une technologie d'ORM ou DataAccess de base.

Pourquoi faire si compliqué ???

Salut, 

Désolé du temps de réponse mais je suis enfin de retour sur le projet. Du coup j'en ai profité pour expliquer un peu mieux le concept de l'application (parce que c'est vrai que ma 1er explication est très vague).

En fait l'application aura cette forme :

Dans le petit encadrer il devra rentrer un requête du style : 

Requête 1 :

Merci d'avance les gars

Ok, la problématique est bien plus claire, mais vous n'avez vraiment rien fait pour simplifier le bidule.

Quand on fait l'expression du besoin, on cherche à se raccrocher à des problématiques connues/classiques et ainsi à les outils classiques de résolution de ces problématiques.

Vous raisonnez en terme de "Table", ce qui est foncièrement lié à de la base de données relationnelle.

Et votre syntaxe est furieusement inspirée de SQL.

Donc, pourquoi réinventer une roue carrée quand les outils de requêtage SQL pullulent ?

S'il y a besoin d'un langage d'interrogation, c'est que c'est le métier qui en a besoin.

C'est le genre de truc qu'on n'impose pas aux utilisateurs finaux.

Si les utilisateurs finaux vous ont sortis une syntaxe à la SQL, c'est que, peu ou prou, ils maitrisent le bidule.

Il est donc essentiel de concevoir en amont le modèle de données relationnel correspondant aux données de votre problème.

Votre exposition des différentes tables manquent beaucoup de clarté et, je pense, serait plus claire en terme de table de de relation "à la SQL/ base de données relationnelles".

Vous devez spécifier clairement la cardinalité de chaque relation entre les différentes Tables dans ce modèle.

Tout cela, ce fait avant même de pisser la moindre ligne de code.

Votre modèle de données doit être cohérent avant même de commencer le développement.

Il peut changer durant le développement mais il doit être cohérent dès le départ.

J'ai du mal à voir le cohérence du modèle que vous nous présenté.

Un "Siège Social" peut travailler sur plusieurs "Industrie" ?

Une "Industrie" peut regrouper plusieurs "Siège Social" ?

C'est quoi ce "0%" qui se balade dans la colonne "12/01/2019" de votre IHM ???

Posez clairement le modèle.

Le langage doit être simple à utiliser sur le modèle, et pas faire un truc compliqué parce qu'on n'a pas réfléchi au modèle en amont.

Le modèle me semble tellement basique que je ne comprends pas l'intérêt d'un langage pour l'IHM.

- une dropdownlist avec la liste des "Industrie"

- une dropdownlist avec la liste des "Siège Social" travaillant dans l'Industrie sélectionnée

- deux contrôles "DateTimePicker" pour donner les dates de début et de fin de la période

- un bouton de recherche

- une grille de visualisation des résultats

Et voilà, une interface compréhensible par les utilisateurs finaux les plus réfractaires et ergonomique et aussi très facile à mettre en place.

Qu'il y ait une basse de données au cul de l'application ou pas, c'est pas le problème. C'est la lisibilité de l'IHM.

Pour le filtrage des colonnes, entre le mot clé "SELECT" et le mot clé "FROM", c'est le genre de truc que fait sans aucun problème un composant grille qui laisse à l'utilisateur la main sur les réglages des colonnes.

Pour le choix de "Action", c'est le nom d'une table/vue de votre modèle. C'est donc une liste finie (voir récupérable depuis la base, si vous faites les choses flexibles), donc facilement sélectionnable dans une simple dropdownlist.

Pour la partie "Langage Naturel", à moins de sortie l'artillerie de l'IA, c'est pas jouable.

C'est une syntaxe que vous devriez créer et elle soit avoir un sens dans ce contexte. Les expressions régulières peuvent souvent suffire.

Mais, en fin de compte : Concevez le modèle de données de votre problème avant même tout développement.

Ce que vous nous montrez simple indiquer que ce modèle n'est pas encore prêt.

Je rejoins bien entendu bacelar, tu te complique la vie pour pas grand chose.

Pour le stockage de tes données, ne te casses pas la tête avec un stockage interne, utilise un SGBD. Si tu veux un SGBD très léger, tu as SQLite qui est gratuit et qui marche très bien pour des bases de données locales monoposte. Tu peux même aller plus loin avec des SGBD bureautiques (MS Office, Star Office, Open Office ...), tout est intégré, je ne pense même pas que tu ai a écrire quoi que ce soit (sauf peut être quelques requêtes SQL plus faciles à écrire à la main, qu'à composer dans les assistants de requêtes de ces outils).

Je me demande même si ce n'est pas encore plus facile à faire avec un tableur (Là, tu as en plus toutes les possibilité de faire des graphiques, histogrammes, tableaux de bord... tout ces trucs dont raffolent les utilisateurs de ce genre de programme) ...

-
Edité par int21h 23 février 2019 à 12:01:24