Reprise du message précédent :

 
Pourtant, ça se fait.

Excel c'est le SGBD le plus utilisé en COGIP, non ?

Malheureusement sans doute oui

à la portée des utilisateurs oui. sinon je pense que le genre SQL est plus répandu en back

Oracle et MSSQL probablement

 
sans faille je ne vois pas
on a tourner dans tous les sens le pblm un operateur qui lance une machine qui ecrit dans un excel pour dire que telle pièce est ok ou non selon des mesures; a un moment T l’opérateur peut accéder aux données modifiable dans l'excel;
car c'est le fichier ...
on veut supprimer le fichier excel pour passer par un truc logique :une bdd
mais non car il faut que l'autre service revalide tout leur process et leur enregistrement;

Verouille les pages de données avec mdp, et seul le formulaire peux écrire des données

Mais  comment la machine ecrit dans le fichier, vu que c'est le profil operateur qui le lance, donc avec son compte
Non c'est excel qu'il faut bannir dans l'industrie c'est tout.
Excel meilleur outil du financier, pas de l'industriel .

 
formulaire avec macro, tu remplis les case de ton formulaire, quand tu cliques sur le bouton "ok", tu déverouille ta feuille de donnée, tu déverses les données, puis tu reverouilles derrière.
 
C'est de la bricole, mais ça marche...

Et si une exception intérromp le processus ? L'utilisateur referme manuellement ?

 
tu fais ce que tu aurai dut faire il y a déjà longtemps :

oui mais à un moment l'operateur a accès aux données
 
Bref Excel BURNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN en industrie.
Car une machine ca déverse en temps réel ses données (certaines, la notre en tout cas)
 
 

Fichiers CSV, nuff said

Et si on passe par une adresse mail? L'opérateur rentre une donnée dans un formulaire, ça envois vers une adresse mail destinée a ça, et dès que l'on ouvre le fichier pour voir le résultat, ça "consulte" les mails pour synthétiser la chose?    
 
Mais le fichier CSV reste une solution plus pratique effectivement

Pitain le nombre de soft que j'ai codée ou le csv est LE format d'échange  
Le programme A chie un fichier csv dans un dossier défini, le programme B scan le dossier, détecte le fichier, l'ouvre, l'intègre puis le déplace dans un dossier " old"  ( oui ... S'il l'efface sans autre forme de procès ça fait chier quand il faut rejouer l'histoire   )
Et il envoie sa réponse sous la forme d'un autre csv dans un autre dossier

Bref .... C'est brutal, c'est moche MAIS c'est tellement simple que ça marche partout, tout le temps

Et si un dev dis qu'il sais pas lire un CSV avec son soft   c'est plus de la chasse ... C'est du braconnage   autant dégommer une chèvre attaché a un piquet  

Bah pour échanger de la donnée entre plusieurs programmes dans un fichier plat, c'est simple et universel le csv.

J'avais une collègue par contre qui dans un même script écrivait ses données temporaire dans un csv pour les relire plus loin dans le même script parce qu'elle comprenaient pas comment utiliser les array

bof, y a des structures de données plus intéressantes comme le xml ou mieux , le json.

Ah bah oui c'est sûr

Comme d'hab tout dépend le besoin...

oui c'est sûr, mais c'était pour répondre au"simple et universel". le format csv ne permet pas tout et peut même complexifier les choses dès lors que la structure n'est pas sous forme de table. après je reconnais qu'un parser csv est ce qu'il y a de plus simple a écrire, alors que json vaut mieux passer par une lib.

Si c'est un script en bash c'est compréhensible.

 
Vrai question, pourquoi ? (je fais pas de bash)
 
On est quasi full M$ ici, du coup on fait du powershell, aucun intérêt de stocker le résultat d'une requête dans un CSV alors que le résultat de la requête est déjà un tableau d'objet qu'il suffit de laisser dans une variable.

On peut faire de l’array en bash

désolé je ne prends que le .sql  pasque le csv c'est piégeux avec des " ou des ; dans des champs texte

Question d'inculte, il y a un interet a utiliser du JSON plutôt que du XML? Je ne connaissais pas le JSON, et a part une autre écriture de XML je vois pas vraiment la différence    
 
Le peu que j'ai lu semble dire que le XML c'est le obselete et le JSON le futur, mais derrière je n'arrive pas a voir de cas ou d'arguments concrets  

Le XML est lourd (dans le sens rapport signal/bruit), y a plein de manières différentes d'encoder les mêmes données, c'est moins évident à lire pour un humain, et pour une machine il faut un schéma.
 
Le JSON c'est un sous-ensemble du Javascript. Donc si ta web app en JS appelle une API qui retourne du JSON, c'est pratique, tu peux utiliser les objets tels quels dans ton code. Ça vaut dans tous les langages au typage dynamique, où désérialiser du JSON est trivial. Le schéma est implicite (c'est ton code, et si tu essaies d'accéder un champs qui n'existe pas, boom). Ça amène bien sûr son lot de problèmes, donc beaucoup de gens sont repassés à des solutions avec un schéma explicite (Protobuf par exemple) ou gèrent la (dé)sérialisation de leur JSON dans des langages statiques, donc de fait avec un schéma explicite.

JSON c'est bien moins verbeux tout en étant très puissant.
On peut mettre un tableau d'objets qui contient lui même un tableau d'objets ...

En plus ça se convertit très facilement en objets Javascript (normal), PHP, .Net ... sans toute l'usine à gaz des parseurs pour XML.
Je préfère donc de loin le JSON au XML.
Seul manque du à sa liberté issue de JS : pas de schéma de validation donc mode d'emploi obligatoire de la structure.

La simplicité c'est une contrainte, c'est tout l'inverse de la puissance.
Les contraintes c'est bien, de manière générale tu veux toujours utiliser l'outil le moins puissant pour ton problème.
 
Mais si tu veux faire des choses puissantes dans un format de sérialisation simple, tu déplaces la complexité ailleurs. Donc vouloir à tout prix éviter des schémas explicites par exemple, c'est vite ingérable.
En XML tu peux faire des choses beaucoup, beaucoup plus puissantes, par exemple: https://www.w3.org/TR/shacl/
 
Gilou va venir nous expliquer tout ça mieux que moi.

 
On peut faire des array mais c'est franchement pas pratique pratique a utiliser, surtout comparé à d'autres langages de scripts comme le python.
(Et pour du shell posix c'est pas possible du tout).

 
En XML aussi

Oui le mot était mal choisi.
"Modularité" était le plus approprié.
Après JSON vs XML c'est comme les bases de données relationnelles vs noSQL, pas la même utilisation.
Pour des API simples, je trouve que c'est bien plus pratique et moins verbeux que XML.

Bof, en pratique si tu offres une API et que tu as des clients un peu oldschool, y en a toujours qui voudront la consommer en XML.
 
De l'autre côté j'ai intégré des sources de fournisseurs qui ne voulaient exposer que du SOAP alors que c'était assez inadapté à notre utilisation.

 
Moins verbeux.
Pas de notion d'attributs.
Sous ensemble des objets en JavaScript.
 
Pour le coup je le trouve plus adapté pour un échange de données via un service REST.
 
Mais ça ne rend pas le XML caduc pour autant, notamment pour l'aspect validation.
 
Et dans la majorité des cas, pas mal d'outils/lib de sérialisation/désérialisation savent gérer les deux formats.
Le mapping est fait pour le XML ? Hop tu as le JSON avec !

Tu as besoin de XML dès que tu as du mixed content, notion qui n'existe pas vraiment en JSON.
 
Perso, je bosse dans l'édition, et les outils sont des outils XML 3.0 (j'insiste sur la version, car le 1.0 ou 2.0 sont a un saut quantique du 3.0, qui est un vrai langage fonctionnel) :
- Schéma en XSD donc XML  (mais dans la réalité vraie, c'est souvent du RNG, donc du XML aussi, s'il est pas sous sa forme compacte)
- données (conformes au schéma) en XML sauvegardées dans une BDD XML native (dont la licence coute un max)
(on fait de la validation multi-schéma en NVDL donc XML)
- Schéma de règles métier en schématron donc XML
- Transfo de données en XSLT, donc XML
- Tests unitaires en Xspec, donc XML
Et bientôt, workflow en XProc 3.0, donc XML (on utilise un truc développé en interne pour le moment)
Ce qui est pas purement XML, mais une techno standard connexe dans mon cas, c'est la partie BDD (XML), ou le langage utilisé pour requêter est du XQuery.
 
Avoir une chaîne conforme a un standard a pas mal d'avantages (un seul validateur pour les contrôler syntaxiquement tous...)
 

C'est bien pour cela qu'en XML 3.0, il y a tout ce qu'il faut pour convertir entre XML et JSON, pour utiliser JSON dans les cas ou il est plus adapté.
 
Le stockage JSON + NoSQL (et plus précisément MongoDB) est pas du tout adapté au stockage de gros document XML avec whatmille niveaux de nœuds et attributs quand c'est un stockage interactif, pour une édition interactive. Trop de récursivité pour reconstruire l'arbre a chaque update.
 
A+,

 
 
Merci, je me coucherais moins bête ce soir  

Faut 10 lignes pour faire ce qui pourrait être fait 2 avec du json.

La perfection n'est pas de ce monde.
 
On peut utiliser swagger pour donner un schéma au système qui va consommer ton api. Si tu es le consommateur, tu peux te fier à ce schéma en général.
 
Avec du xml, tu peux aussi te retrouver avec des données de merde avec les vieilles api de derièrre les fagots.  
 
En conclusion :

 
C'est exactement pour ça qu'on doit pas faire évoluer des techs en manager quand ils sont bons

Puisqu'on en est aux questions existentielles  
Vous prononcez comment JSON?

 
jizone

Jayzon  

 
C'est pour ça qu'on m'a refusé le poste de manager quand j'ai postulé ils ont pas voulu me lâcher du poste où je me trouvais, en m'expliquant "..blabla ... c'est fini le temps des techniciens experts qui passent manager par ancienneté ... blabla... les managers sont pas forcément mieux payés que les techniciens experts ...blabla...".
 
Bon quand je vois tous les tableaux excel qu'on demande à celui qui a pris la place que je convoitais, finalement, c'est pas plus mal, et  je lui ai refilé tout le boulot administratif ( non technique ) que je faisais