Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Windows Windows Serveur SQL Serveur [HS] Comment gérer ce problème d'import/modelisation

[HS] Comment gérer ce problème d'import/modelisation

8 réponses
Avatar
Jérôme Quintard
Salut à tous,

J'ai besoin qu'on me donne des idées pour un problème simple mais
terriblement complexe par ses conséquences.

J'ai une base de données avec deux tables du genre :

tblDepartements
IdDepartement
Libelle

tblVilles
IdVille
IdDepartement
Libelle

Pour un 'departement' je peux donc avoir une infinité de 'villes'. Jusque là
rien de sorcier. Mon problème est le suivant, j'ai besoin d'importer des
informations en provenance de différents logiciels tiers. Certains sont
biens faits et utilise ce genre de modèle, d'autres utilise celui-ci :

tblVilles
IdVille
LibelleDepartement <- Département en texte
Libelle

Du coup comment faire pour renseigner correctement mes tables ? Je peux très
bien faire une correspondance et ajouter les élements problématique, aucun
problème (bien qu'ajouter 'ienne' parce que l'utilisateur à oublier le 'V'
m'embête :o) mais ç'est là que ça ce complique car j'ai deux niveaux
d'utilisation :

Utilisation locale : le type entre les données sur son soft et importe les
données des logiciels tiers lorsqu'il fait des MAJ dessus. Dans ce cas, pas
grave si l'on ajoute des données style 'ienne' au lieu de 'Vienne' lorsque
il n'y a pas de correspondance ça reste au niveau locale et pas trop grave
(le type aura par contre un département du nom de 'ienne' dans sa table).

Utilisation nationale : les données sont reprises au niveau nationale via
l'internet. Je veux donc éliminer au maximum tout problème de saisie lors
des non correspondances. Car je ne peux pas me permettre que chaque
utilisateur ajoute des données style 'ienne' et autres erreurs de saisie
dans la base. Je ne veux pas non plus que par exemple dans la liste des
départements ont se retrouve avec un 'ienne'.

Donc en bref.... Quelqu'un à t'il une idée comment gérer ce truc ?????????
Je suppose que je suis pas le premier à me poser ce genre de question.

Merci à tous,

Jérôme
Signaler un problème avec ce contenu

8 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Laurent Moreau
Pour ton probleme, des le départ j'utiliserais les données de l'INSEE avec
l'ensemble des communes et des départements.

Ensuite prendre la décision de corriger une erreur de saisie est toujours
délicat.


Tu peux faire des tables de décision basées sur l'historique des erreurs
rencontrées
ex une table avec 2 champs: MauvaiseSaisie, ValeurARetourner
ienne -> Vienne

Idem pour les noms de ville:
Tououse -> Toulouse

Mais, Il te faudra également gérer les problemes de cohérence: si tu recois
une saisie qui dit que Toulouse est dans la Vienne...


En fait, je pense qu'il faut retourner a un administrateur le résultat de
ton chargmeent, dans le lequel on trouve les erreurs rencontrées.


J'espère d'avoir donné quelques idées.

Laurent.





"Jérôme Quintard" wrote in message
news:evAH%
Salut à tous,

J'ai besoin qu'on me donne des idées pour un problème simple mais
terriblement complexe par ses conséquences.

J'ai une base de données avec deux tables du genre :

tblDepartements
IdDepartement
Libelle

tblVilles
IdVille
IdDepartement
Libelle

Pour un 'departement' je peux donc avoir une infinité de 'villes'. Jusque


là
rien de sorcier. Mon problème est le suivant, j'ai besoin d'importer des
informations en provenance de différents logiciels tiers. Certains sont
biens faits et utilise ce genre de modèle, d'autres utilise celui-ci :

tblVilles
IdVille
LibelleDepartement <- Département en texte
Libelle

Du coup comment faire pour renseigner correctement mes tables ? Je peux


très
bien faire une correspondance et ajouter les élements problématique, aucun
problème (bien qu'ajouter 'ienne' parce que l'utilisateur à oublier le 'V'
m'embête :o) mais ç'est là que ça ce complique car j'ai deux niveaux
d'utilisation :

Utilisation locale : le type entre les données sur son soft et importe les
données des logiciels tiers lorsqu'il fait des MAJ dessus. Dans ce cas,


pas
grave si l'on ajoute des données style 'ienne' au lieu de 'Vienne' lorsque
il n'y a pas de correspondance ça reste au niveau locale et pas trop grave
(le type aura par contre un département du nom de 'ienne' dans sa table).

Utilisation nationale : les données sont reprises au niveau nationale via
l'internet. Je veux donc éliminer au maximum tout problème de saisie lors
des non correspondances. Car je ne peux pas me permettre que chaque
utilisateur ajoute des données style 'ienne' et autres erreurs de saisie
dans la base. Je ne veux pas non plus que par exemple dans la liste des
départements ont se retrouve avec un 'ienne'.

Donc en bref.... Quelqu'un à t'il une idée comment gérer ce truc ?????????
Je suppose que je suis pas le premier à me poser ce genre de question.

Merci à tous,

Jérôme




Avatar
Fred BROUARD
il suffit de proposer un référentiel unique et accessible à tous.

Par exemple la liste complete des villes / CP par département.

A lire :
http://sqlpro.developpez.com/Normes/SQL_normes.html
chapitre 3 en particulier...

A +

Jérôme Quintard a écrit:
Salut à tous,

J'ai besoin qu'on me donne des idées pour un problème simple mais
terriblement complexe par ses conséquences.

J'ai une base de données avec deux tables du genre :

tblDepartements
IdDepartement
Libelle

tblVilles
IdVille
IdDepartement
Libelle

Pour un 'departement' je peux donc avoir une infinité de 'villes'. Jusque là
rien de sorcier. Mon problème est le suivant, j'ai besoin d'importer des
informations en provenance de différents logiciels tiers. Certains sont
biens faits et utilise ce genre de modèle, d'autres utilise celui-ci :

tblVilles
IdVille
LibelleDepartement <- Département en texte
Libelle

Du coup comment faire pour renseigner correctement mes tables ? Je peux très
bien faire une correspondance et ajouter les élements problématique, aucun
problème (bien qu'ajouter 'ienne' parce que l'utilisateur à oublier le 'V'
m'embête :o) mais ç'est là que ça ce complique car j'ai deux niveaux
d'utilisation :

Utilisation locale : le type entre les données sur son soft et importe les
données des logiciels tiers lorsqu'il fait des MAJ dessus. Dans ce cas, pas
grave si l'on ajoute des données style 'ienne' au lieu de 'Vienne' lorsque
il n'y a pas de correspondance ça reste au niveau locale et pas trop grave
(le type aura par contre un département du nom de 'ienne' dans sa table).

Utilisation nationale : les données sont reprises au niveau nationale via
l'internet. Je veux donc éliminer au maximum tout problème de saisie lors
des non correspondances. Car je ne peux pas me permettre que chaque
utilisateur ajoute des données style 'ienne' et autres erreurs de saisie
dans la base. Je ne veux pas non plus que par exemple dans la liste des
départements ont se retrouve avec un 'ienne'.

Donc en bref.... Quelqu'un à t'il une idée comment gérer ce truc ?????????
Je suppose que je suis pas le premier à me poser ce genre de question.

Merci à tous,

Jérôme





--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
Jérôme Quintard
Oui merci Laurent, sauf que j'ai donné un exemple (j'aurrai pas du :) avec
des villes et des départements mais au final les données non rien à voir :)
Avatar
Jérôme Quintard
Merci Fred, sauf que comme je disais plus haut, c'est pas limité à des
tables Départements / Villes.

Mais plutôt :

Catégories -> Produits -> Secteurs

etc...

Tu ferais comment toi spécialiste devant l'éternel pour gérer ce problème
???

Merci

Jérôme
Avatar
Fred BROUARD
Une base centralisée, accessible par intranet.

Y'a pas d'autres solution si tu veut impérativement respecter le référentiel.
Sinon il y aura toujours un delta et des conflits à résoudre à la main. Et l'expérience montre qu'au bout d'un certains
temps les conflits ne sont plus gérés et la base devient une poubelle !

A +

Jérôme Quintard a écrit:
Merci Fred, sauf que comme je disais plus haut, c'est pas limité à des
tables Départements / Villes.

Mais plutôt :

Catégories -> Produits -> Secteurs

etc...

Tu ferais comment toi spécialiste devant l'éternel pour gérer ce problème
???

Merci

Jérôme





--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
Fred BROUARD
Une base centralisée, accessible par intranet.

Y'a pas d'autres solution si tu veut impérativement respecter le référentiel.
Sinon il y aura toujours un delta et des conflits à résoudre à la main. Et l'expérience montre qu'au bout d'un certains
temps les conflits ne sont plus gérés et la base devient une poubelle !

A +

Jérôme Quintard a écrit:
Merci Fred, sauf que comme je disais plus haut, c'est pas limité à des
tables Départements / Villes.

Mais plutôt :

Catégories -> Produits -> Secteurs

etc...

Tu ferais comment toi spécialiste devant l'éternel pour gérer ce problème
???

Merci

Jérôme





--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************
Avatar
Nathan NAU
"Fred BROUARD" a écrit dans le message de
news:%
Une base centralisée, accessible par intranet.

Y'a pas d'autres solution si tu veut impérativement respecter le


référentiel.
Sinon il y aura toujours un delta et des conflits à résoudre à la main. Et


l'expérience montre qu'au bout d'un certains
temps les conflits ne sont plus gérés et la base devient une poubelle !



Le probleme pour ce projets n'est pas rellement le delta, mais plutot la
resolution des conflits...

Nathan

A +

Jérôme Quintard a écrit:
> Merci Fred, sauf que comme je disais plus haut, c'est pas limité à des
> tables Départements / Villes.
>
> Mais plutôt :
>
> Catégories -> Produits -> Secteurs
>
> etc...
>
> Tu ferais comment toi spécialiste devant l'éternel pour gérer ce


problème
> ???
>
> Merci
>
> Jérôme
>
>

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************



Avatar
Nathan NAU
"Fred BROUARD" a écrit dans le message de
news:%
Une base centralisée, accessible par intranet.

Y'a pas d'autres solution si tu veut impérativement respecter le


référentiel.
Sinon il y aura toujours un delta et des conflits à résoudre à la main. Et


l'expérience montre qu'au bout d'un certains
temps les conflits ne sont plus gérés et la base devient une poubelle !



Le probleme pour ce projets n'est pas rellement le delta, mais plutot la
resolution des conflits...

Nathan

A +

Jérôme Quintard a écrit:
> Merci Fred, sauf que comme je disais plus haut, c'est pas limité à des
> tables Départements / Villes.
>
> Mais plutôt :
>
> Catégories -> Produits -> Secteurs
>
> etc...
>
> Tu ferais comment toi spécialiste devant l'éternel pour gérer ce


problème
> ???
>
> Merci
>
> Jérôme
>
>

--
Frédéric BROUARD, MVP SQL Server. Expert SQL / spécialiste Delphi, web
Livre SQL - col. Référence : http://sqlpro.developpez.com/bookSQL.html
Le site du SQL, pour débutants et pros : http://sqlpro.developpez.com
************************ www.datasapiens.com *************************