Bonjour,
 
 
Dans le cadre d'un projet perso, je dois afficher, modifier et sauvegarder des fichiers Excel dans une base de données.
Le problème est (en plus d'être sur un clavier qwerty que je découvre et sur lequel je ne sais pas faire les accents) que l'on souhaite que l'utilisateur puisse faire un copier/coller de son fichier sur une interface, pour ensuite travailler sur le site.
 
Donc pas d'import de CSV et aucun contrôle de ce qui rentre dans l'interface.
 
J'ai passe un peu de temps avec HandsOnTable, qui me permet de faire le copier/coller sur l'interface, puis de sauvegarder les données en base. J'ai essaye de déstructurer le fichier en entrée, j'ai donc une table avec les entêtes et une table avec les données.  
La table avec les entêtes contient un id unique, l'identifiant du fichier source, la valeur de l'entête, le numéro de colonne et si ce champ fait partie d'une catégorie de champs obligatoires.
La table des données contient un lien vers l'id entête pour savoir dans quelle colonne se trouve la valeur, ainsi que la valeur dans le fichier source.
 
Bon, j'ai un peu galéré a mettre tout ca en place mais ca fonctionne.  
 
Mes questions sont :  
 
- quelle serait la meilleure façon de procéder pour répondre a cette problématique. J'ai vraiment l'impression que je suis parti pour me prendre la tête avec la déstructuration, et je me demandais si je n'irais pas plus vite a créer une table par fichier (il n'y a que quelques centaines de lignes max par fichier, donc pas de soucis pour les index etc.), voire une seule table avec une centaine de colonnes qui stockerait juste le fichier brut.
 
- l'utilisation de ces fichiers en base sera assez basique au début : sauvegarder des données, remplir des champs manquants grâce a des appels lances par des batches, projection sur des quantités etc.
 
Je ne peux absolument pas imposer un format en entrée, tout au plus je peux forcer l'utilisateur a m'indiquer quels sont les champs obligatoires (j'ai par exemple toujours besoin d'une quantité, donc j'ai créé une table de mots clés associes a une catégorie et je demande a ce qu'au moins une colonne du fichier ait pour entête "qty" ou "qte" ou "quantity" etc. (c'est paramétrable en bdd et ca fonctionne déjà), par exemple :
QUANTITY : qty, qte, quantity etc.
PRODUCT NAME : name, product, etc.
 
En écrivant la question, je me dis que sauvegarder le fichier brut dans une table "en vrac", le charger dans une table construite a la volée si l'utilisateur souhaite travailler dessus, et faire l'opération inverse a la sauvegarde semble bien plus simple que de ne travailler qu'avec "l'état de l'art" d'une structure universelle mais qui risque d'être très galère a faire évoluer et a maintenir.
 
Merci pour vos avis !

Tu peux proposer dans l'IHM web (donc en HTML/CSS/Javascript) un champ de type file pour uploader le fichier csv ainsi qu'une grande zone de texte (textarea) pour pouvoir copier/coller du CSV dedans (et dans ce cas, un petit champ input pour préciser le séparateur). Ensuite, tu as un bouton "submit" pour poster au serveur tes données. Côté serveur, tu as quoi comme langage ? Tu peux prendre du PHP.
Tu analyses le contenu des champs (soit le file est rempli soit c'est la zone de texte).
Si c'est le file, tu récupères le fichier et tu lies son contenu (y'a des fonctions en PHP pour lire du CSV). Tu mets tout ça dans une variable de type Array.
Si c'est la zone de texte, tu parses ton CSV et tu mets dans une variable de type Array
 
Dans tous les cas, après, tu analyses le contenu de ta variable Array et tu fais les vérifs nécessaires avant de mettre chaque enregistrement dans ta BD. Bien évidemment, au préalable, tu dois avoir modélisé tes tables pour avoir une BD normalisée (3NF par ex : https://fr.wikipedia.org/wiki/Forme [...] me_normale ).
 
Après, si les données attendues peuvent être n'importe quoi (donc la structure est pas connue), là, ça va être plus chaud si tu veux en tirer une forme normalisée et créer de manière automatique la BD Dans ce cas, je dirais que le plus simple c'est de faire une seule table. Après, faut voir aussi le volume. Si c'est très gros, peut-être se tourner vers du NoSQL...

Bonjour Rufo,

Merci pour la réponse. Tout ce qui concerne l'IHM est en bonne voie, j'ai utilisé HandsOnTable qui permet de coller le contenu d'un fichier Excel  et qui ajuste automatiquement le format. Il fournit aussi pas mal de méthodes assez pratiques, et j'ai déjà fait la partie JS pour contrôler les données et le service PHP qui récupère le Json pour l'intégrer en base.
Aujourd'hui j'ai voulu normaliser au mieux en créant des tables clés/valeurs pour stocker mes fichiers, mais je pense que ça va énormément compliquer les traitements, donc je pense que je vais partir vers une table qui référence les fichiers, et ensuite créer une table par fichier. Ça n'est pas la solution idéale, mais je sais déjà que les fichiers en entrée auront des formats très différents, et reconstruire exactement ce qui a été fourni en historisant les modifications risque d'être une grosse prise de tête.