Salut et désolé pour le titre bateau !
 
Tous les jours j'envoi dans le cadre de mon boulot un fichier structuré au format txt.
Il s'agit d'une liste de colis avec comme champs entre autres la date, le poids, le code postal,...
Il y a entre 5 et 200 lignes dans chaque fichier.
 
Ce que je souhaiterais c'est un moyen de pouvoir intégrer ce fichier dans une base (à priori une base avec une seule table suffira) de façon quotidienne.
Chaque jour il suffirai de charger le fichier txt créé par ailleurs ce qui injecterai les données dans ma table et rajouterai aux lignes des jours précédents les lignes du jour.
 
Le but est de pouvoir sortir des états et enrichir la base  
Ex :
- Requete permettant d'afficher le nb de colis envoyés dans un département pour un mois donné.
- Possibilité de rajouter des infos dans autant de champs "à remplir manuellement" (au clavier) du type :  
       - colis arrivé? (oui ou non)
       - colis facturé par le prestataire de transport
       - date facturation par ce prestataire
En gros il s'agirai de pouvoir "lettrer" ces colis.
 
Je suis en train de voir le couple MySQL et MySQL-front.
J'arrive à importer les données sans aucun problème et pour les requêtes ça à l'air possible.
Il semble qu'on puisse "entrer" des données directement dans la table via l'IHM de MySQL-front.
 
Je précise que bien qu'ayant à peu près compris le fonctionnement d'un SGBD etplus globalement "ce qui se passe", je n'ai aucune notion de SQL.
J'imagine toutefois que les requetes qui m'interesse n'ont rien d'insurmontable et que quelques heures de trifouillage devrait dans l'absolu me permettre d'arriver à quelque chose.
 
Ce que je voudrais simplement savoir c'est si ce couple MYSQL et MySQL front vous semble adapter à ma problématique.
 
je ne suis arrêté sur aucune solution SGBD et n'ai rien contre ACCESS si cela vous parait une meilleure solution.
 
En vous remerciant d'avance.
 
Cordialement.
 
Frank
 
 

 
Hello
 
Le découpage de data en tables est aussi un travail qu'il faut faire. Bon, je ne vais pas te faire de grande théorie mais imaginons que tu veuilles gérer une bibliothèque (titre, nb, auteur), vas-tu stocker les data dans une table, style
20.000 lieues sous les mers, 50, Jules Verne
De la Terre à la lune, 12, Jules Verne
Le rayon vert, 8, Julesss Verne
Le père Goriot, 4, Victor-Hugo
 
Ou de cette façon
Table des auteurs (id, nom)
1, Jules Verne
2, Victor-Hugo
 
Table des livres (titre, nb, idAuteur)
20.000 lieues sous les mers, 50, 1
De la Terre à la lune, 12, 1
Le rayon vert, 8, 1
Le père Goriot, 4, 2
 
Tu vois la différence ? Dans le second cas,
- tu gagnes en espace (stocker "n" identifiants est moins gros que stocker "n" noms (sans compter les erreurs possibles lors de la saisie comme pour mon 3° livre))
- changer un nom d'auteur (par exemple remplacer "Jules Verne" par "Verne, Jules" ) ne requiert qu'une seule modif dans le second cas, et autant de modif qu'il y a de livres dans le premier cas.
 
Donc tant qu'à te lancer dans une bdd, autant essayer d'étudier un peu le truc...
 
 

Classique
 

Classique
 

Arf, c'est un langage qui s'apprend. Mais il existe aussi des outils d'interface graphique qui se chargent de faire le SQL à ta place. Toutefois, c'est quand-même bien de le connaitre afin de pouvoir intervenir plus finement quand le besoin s'en fait sentir...
 

Absolument
 

Tout à fait. Moteur bdd fiable, opensource. Il a bien sûr des limites qui l'empêchent d'être utilisé dans de très grosses structures mais je veux parler de structures brassant des milliers et des milliers de data (style NASDAQ) dont tu es très loin.
Tu peux l'interfacer ensuite avec des outils internet comme phpMyAdmin et t'as même des outils professionnels de visu/interface comme MySQLMaestro (payant mais il y en a plein d'autres GPL)
 

On peut pas répondre à ta place. Ce que je sais d'Acces, c'est que l'accès multiple n'existe pas. Le premier qui ouvre ta bdd gagne le jeton d'écriture et les autres ne peuvent l'ouvrir qu'en lecture seule. A la limite, tu pourrais aussi bien faire ton truc aussi sous Excel si tu t'en sors mieux. Ou dans un simple fichier notepad aussi.
 
L'avantage d'une vraie bdd, c'est qu'elle gère les clients multiples, sait verrouiller les data contre les accès concurrents, gère l'atomicité d'une transaction (si tu as besoin de 4 modifs sur 4 infos/tables différentes pour enregistrer une livraison de colis et que la bdd plante à la 3° modif, elle annule tout afin que ta bdd reste stable => certes la livraison n'est pas enregistrée mais ta bdd reste cohérente et on peut recommencer les modifs de zéro). C'est plus que de la simple data stockée de ci, de là...

Merci pour ta réponse.
Pour être plus précis voilà la problématique.
 
La société dans laquelle je bosse stocke de la marchandise pour un client.
Tous les jours nous recevons pour ce client un fichier qui dit en gros telle marchandise pour tel client qui habite à tel endroit.
Ce fichier est injecté dans un soft fourni par notre prestataire pour le transport et en sortie on se retrouve avec l'étiquette du colis, un bordereau et surtout un fichier récapitulant les détail de chaque colis (hormis son contenu) c'est à dire le poids, le destinataire, le tarif, la date, etc...
 
Chaque fin de mois on reçoit un état de notre prestataire qui récapitule les colis transportés et dont découle la facturation.
 
Ce que je voudrais c'est donc suivre de façon plus fine cette facturation en ayant un outil me permettant par exemple :
- de lettrer ces colis une fois qu'ils sont facturés
- de noter des commentaires,
- ...
 
Pour le découpage par tables au lieu d'en avoir une seule grosse, je comprend l'intérêt et vais aller dans ce sens.
Les données n'étant pas spécialement recurrente dans mon application je pensais que ce serais plus simple de faire une seule table mais effectivement autant faire les choses proprement.
 
Pour les soft merci du tuyau. De toutes façons à un moment où à un autre il faudra bien que je comprenne ce qui se passe donc il va bien falloir que j'apprenne à baragouiner du SQL ! Ou au moins à le comprendre.
 
Pour le SGBD, ACCESS serait suffisant car je n'ai pas de besoin multi utilisateur.
Ce que je me disais c'est que j'avais là une bonne occasion de mourir un peu moins bête et que quitte à investir du temps dans l'apprentissage de quelque chose il valait mieux le faire dans un système beaucoup moins limitatif qu'ACCESS.
Attention, je ne dis pas qu'ACCESS est un truc pour les enfants...Je pense juste que peut-être qu'un jour j'aurais besoin de faire du multi utilisateurs et que du coup ce que j'aurais appris sur ACCESS ne me servira plus...Du coup autant partir direct sur MySQL et les front autour.
 
En tout cas merci pour tes précieux conseils !
 
 

Attention aussi à ne pas trop découper. La complexité d'une bdd ne se calcule pas par rapport aux nombres d'infos d'une table (une table peut très bien avoir 60, 80, 100 infos par enregistrement) mais par la gestion des cardinalités
Concrètement, pour toute data A associée à une data B dans une relation 1/1 (une data A est liée à une data B), alors on stocke la data A et B ensemble
Exemple: un colis n'a qu'une seule adresse de livraison => tu stockeras le n° de colis et l'adresse dans la même table
 
Pour toute data A associée à "n" data B dans une relation (1,1)/(1,n), alors on stocke la data A dans une table à part avec un identifiant et on recopie cet identifiant dans la table qui stocke la data B
Exemple: un livre n'a qu'un auteur alors qu'un auteur écrit plusieurs livres => voir mon exemple de mon post précédent => une table d'auteurs et l'identifiant de l'auteur recopié dans la table des livres
 
Pour toute data A associée à "n" data B dans une relation (1,n)/(1,n), alors on stocke la data A dans une table à part avec un identifiant, la data B dans une table à part avec un identifiant et on crée une table de relation dans laquelle on recopie l'identifiant de la data A et celui de la data B
Exemple: une personne peut avoir plusieurs appartements, et un appartement peut être propriété de plusieurs personnes (multipropriété)
Tu auras donc
- la table des personnes
Paul, 1p
Jean, 2p
Pierre, 3p
 
- la table des appartements
Chantilly, 1a
Versailles, 2a
Senat, 3a
 
- la table de liaison (généralement nommée par/avec un verbe style "est propriétaire" )
1p, 1a
1p, 2a
1p, 3a
2p, 3a
3p, 1a
Et qui se lira
- Paul (1p) est propriétaire de Chantilly (1a)
- Paul (1p) est propriétaire de Versailles (2a)
- Paul (1p) est propriétaire du Senat (3a)
- Jean (2p) est propriétaire du Senat (3a)
- Pierre (3p) est propriétaire de Chantilly (1a)
 
Et qui peut se lire aussi dans l'autre sens
- Chantilly (1a) est possédé par Paul (1p)
- Chantilly (1a) est possédé par Pierre (3p)
- Versailles (2a) est possédé par Paul (1p)
- Le Senat (3a) est possédé par Paul (1p)
- Le Senat (3a) est possédé par Jean (2p)
 

On est là pour ça... parce qu'on aime ça  

OK, en fait ce que je compte faire c'est un table à part pour les codes postaux, une pour les ref clients et une pour les dates, tous le reste sera dans une seule table.
 
Encore merci !

Avec la ville avec...
 
C'est amusant que tu aies identifié cette data car elle fait partie de la "boyce-codd".
En général, quand on construit une bdd, on cherche à éviter les redondances. C'est pour ça qu'on identifie les cardinalités afin que les redondances ne se fassent que sur les identifiants.
Toutefois, le code postal est une data qui implique une redondance qu'on ne peut pas supprimer. En effet, avec une ville et un département on peut obtenir un code postal, et avec un code postal on peut obtenir le département. Cette redondance qui se mord à moitié la queue mais qu'on ne peut pas supprimer a été identifié par Boyce et Codd qui lui ont donné leur nom.  
 

Tiens ? T'as dû lire des trucs car généralement, les débutants ne pensent pas à mettre les dates à part. Mais effectivement, c'est conseillé...
 

Ouaip. Comme un colis semble (dans ta description) adressé qu'à un seul client, ce sera la table des colis qui reprendra l'identifiant du client pour qui c'est adressé.
 
Ici, plus de détails sur la façon de découper les infos http://laurent-audibert.developpez [...] BD016.html

Pour les dates promis j'ai rien lu...
 
Merci pour le lien, je vais lire ça à tête reposée ce soir.
 
Je vais me mettre dès ce soir sur mon MDD (purée ça me rappelle mes cours d'access en fac...)
 
Encore merci pour les conseils