Information données sur requete sql

Version imprimable

07/07/2023, 11h44
android59

Information données sur requete sql

Bonjour,
je développe une interface en php, utilisant une bdd sous phpmyadmin /mysql.
La première étape que je réalise actuellement c'est l'import de fichier excel, correspondant respectivement aux noms de mes différentes tables exemple :

Voici le contexte:
Chaque jours des fichiers excels nous sont mis à disposition dans un répertoire.

Fichier excel 1:
nop, prenom, age, date

Fichier excel 2 :
nom, prenom, nom entreprise, ancienneté, etc...

Fichier excel 3:
identifiant entreprise, numero salarie, numero_anomalie, solde,etc...

Dans ma bdd mysql, j'ai donc les tables suivants :
table1: idtable1 , nom,prenom,age,date
table2: idtable2,nom, prenom, nom_entreprise,ancienneté
table3: idtable3, identifiantentreprise, numero_salarie, numero_anomalie, sole,...

J'ai réalisé cette tache manuellement, en les important et pour chaque table, j'ai rajouté un id.

Avant de construire ma base de données, j'ai précaunisé de rajouter un champ "date_enregistrement" ou date_import, afin que pour plus tard, nous pourrions faire une condition sur la date d'import dans la base de données, afin de faire des comparatifs des résultats retournées, mais on m'a dit que ce n'était pas utile et qu'il fallait juste se fier au dernier id.....

De mon point de vue, ça n'a rien à voir, car l'id est en autoincrement et lorsque je débuterais la 2eme partie de mon traitement, qui consiste à importer automatiquement les fichires excel dans la base de données, sans le champs " date import " ou "date enregistrement" nous n'aurons pas la possibilité de faire le distingo entre les données, importé hier et celles importés il y a deux semaines.

A votre avis, est ce que je ferais mieux de rajouter un champ "date d'enregistrement" dans chaque table?
J'ai pensé à cette exemple, car quand j'avais accès à une base de données de notre entreprise, dans chaque table on avait un champs "date creation" et "user creation" et je pense que ses champs, pour des raisons de traçabilité, sont necessaire.
qu'en pensez vous?

Merci
07/07/2023, 17h12
Séb.

Citation:

Avant de construire ma base de données, j'ai précaunisé de rajouter un champ "date_enregistrement" ou date_import, afin que pour plus tard, nous pourrions faire une condition sur la date d'import dans la base de données, afin de faire des comparatifs des résultats retournées, mais on m'a dit que ce n'était pas utile et qu'il fallait juste se fier au dernier id.....

Sur ce type d'exercice c'est, comme tu l'as pressenti, extrêmement important de connaître la date d'import. Cela te permet de dater tes données à moindre coût et de vérifier facilement si les imports se déroulent correctement.
Par ailleurs l'ID n'est en rien fiable pour établir une chronologie, ce n'est tout simplement pas son rôle.

Citation:

A votre avis, est ce que je ferais mieux de rajouter un champ "date d'enregistrement" dans chaque table?

Oui.

Comment vas-tu procéder ? Écrases-tu/complètes-tu l'existant à chaque fois ou bien conserves-tu l'historique des différents fichiers ?

Je te conseille de modéliser au mieux ta bdd dès le début
=> 1 fichier n'est pas forcément égal à 1 table, je vois par exemple des colonnes "nom" et "prenom" qui se répètent
10/07/2023, 14h32
android59

Merci pour ce retour.
Actuellement je suis en phase de développement, je fais mes tests au fur et à mesure que je développe mon code, pour chaque onglet que je rajoute.

J'utilise des fichiers réels pour mes tests, comme ça je peux adapter mon code en fonction de certains fichiers.
Par exemple, j'ai certains fichiers qui font 100 000 lignes ( plus ou moins quelques lignes ) et j'ai remarqué que mon programme a du mal, du coup soit j'adapte le temps d'execution de mon code, soit je met l'onglet en "orange" ce qui veut dire que je dois repasser dessus.

Une fois que j'ai créé tout mes onglets, je refais une passe minutieuse sur chaque fichier, puis une fois en prod, je vide ma base de données et roulé jeunesse.
Je vais dors et déjà voir pour rajouter une colonne "date_import" dans chaque table.
11/07/2023, 14h38
escartefigue

Bonjour,

L'une des difficultés va être de déterminer les vraies correspondances entre les lignes des différents fichiers.
Par exemple, des doublons sur nom+prénom sont très probables si le fichier est un tant soit peu volumineux.
Les "jacques martin" sont légion, mais ce ne sont pas tous les mêmes
Il en va de même avec la raison sociale des entreprises, les "hotel bellevue", "coiffeur infinitif" ou "bar des sports" sont également très nombreux, pour autant ce ne sont pas les mêmes.
Donc, pour fiabiliser et votre BDD et vos rapprochements, il est nécessaire d'ajouter des identifiants fonctionnels fiables tels que le NNI ou NIR pour les individus et le SIRET pour les entreprises françaises (ou équivalent pour les étrangères, par exemple le n° de TVA intracommunautaire).
29/01/2025, 09h31
android59

Bonjour,
merci bien pour le retour.
08/02/2025, 08h07
pier.antoine

Bonjour

Je pense comme Seb, qu'il serait prudent de modéliser la base avant de gérer les imports.

Gérer les imports, c'est technique. Ce n'est pas forcément très complexe.
Par contre, faire en sorte que toute les données soient faciles à gérer (savoir les repérer, éviter les doublons, limiter les traitements...) demande plus de travail en amont.

Ainsi, dans votre exemple, je ferai l'importation des fichiers dans un autre ordre :
- Fichier 1 > à insérer dans une table "individu"
- Fichier 3 > à insérer dans une table "Entreprise"
- Fichier 2 > à insérer dans une table association "Individu entreprise", dans laquelle on y stockerait les références de l'individu, de l'entreprise et l'ancienneté.

Bon courage
Pierre
10/02/2025, 07h37
escartefigue
Effectivement, la modélisation des données est une étape cruciale à tout point de vue, mais, pour pouvoir le faire, il faut connaitre les règles de gestion.

Par exemple, est-ce qu'une même personne peut ou pas être affectée à plusieurs entreprises à un instant "t"
Si la réponse est oui, alors l'association personne<-> est n-aire et deviendra une table
Si la réponse est non, alors l'association personne <-> entreprise ne deviendra pas une table.
Et selon qu'on a ou pas besoin de connaitre l'historique d'affectation d'une personne à une entreprise, on aura une association faisant participer la date, donc éventuellement une association ternaire.

Ensuite, comme je l'indiquais dans ma réponse précédente, il est obligatoire d'avoir d'autres informations que celles de ces fichiers pour pouvoir déterminer un individu ou une entreprise
Nom + prénom pour un individu c'est très insuffisant, on peut avoir affaire à des homonymes.

Quant à ceci :

Citation:

Envoyé par android59

Dans ma bdd mysql, j'ai donc les tables suivants :
table1: idtable1 , nom,prenom,age,date
table2: idtable2,nom, prenom, nom_entreprise,ancienneté
table3: idtable3, identifiantentreprise, numero_salarie, numero_anomalie, sole,...

C'est à peu près tout ce qu'il ne faut pas faire

Table1 : à de très rares exceptions près, on ne stocke jamais l'âge d'une personne, mais sa date de naissance à partir de laquelle on calcule l'âge quand on en a besoin
Table2 : comme c'est une table associative, elle ne doit pas avoir d'identifiant propre, son identifiant sera formé soit du couple (id personne, id entreprise) soit du trio (id personne, id entreprise, date) en fonction de la règle de gestion que j'ai mentionnée ci-dessus.
Table3 : les données d'un salarié n'ont rien à faire dans une table dont l'identifiant est l'entreprise

Pour éviter tous ces écueils de débutant :
1. formalisez les règles de gestion, prenez exemple sur ce fil de discussion pour le formalisme ;
2. établissez un Modèle Conceptuel des Données (MCD) avec un logiciel de modélisation (surtout pas avec Workbench !), je vous recommande l'excellent Looping que vous pouvez télécharger gratuitement ICI.