Discussion :

[android59]

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

[S�b.]

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.

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

[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.

[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).

[android59]

Bonjour,
merci bien pour le retour.

[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

[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 :

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.