Les noms des entreprises calées différemment par différentes personnes

Question

Je possède ce tableau

tblStore 

avec ces champs

storeID (autonumber) 
storeName 
locationOrBranch 

et ce tableau

tblPurchased 

avec ces champs

purchasedID 
storeID (foreign key) 
itemDesc 

Dans le cas de magasins ayant plusieurs emplacements, un problème se pose lorsque deux personnes affectent par inadvertance le même emplacement de magasin. Par exemple, prenez Harrisburg Chevron. Sur certaines de ses recettes, il s'appelle Harrisburg Chevron, certains disent juste Chevron au sommet, et sous cela, Harrisburg. Une personne peut le saisir dans tblStore comme storeName Chevron, locationoOrBranch Harrisburg. Person2 peut le saisir comme storeName Harrisburg Chevron, locationOrBranch Harrisburg. Ce qui rend ce mauvais est que le nom de l'entreprise est Harrisburg Chevron. Il semble difficile de faire une règle (qui couvrirait de manière compréhensible toutes les opportunités futures pour cette erreur) pour empêcher les gens de faire cela à l'avenir.

Question 1) Je pense que lorsque les instances sont trouvées, une requête de mise à jour pour changer tous les enregistrements d'une façon à l'autre est la meilleure façon de le réparer. Est-ce correct?

Questions 2) Quelle serait la meilleure façon d'avoir à l'origine configuré le db pour l'éviter?

Question 3) Que puis-je faire pour faciliter les corrections ultérieures après coup lorsque cela se produit?

Merci.

modifier: Je comprends que de meilleures pratiques commerciales sont la prévention idéale, mais pour la question 2 Je cherche des conseils ou des astuces que les gens utilisent qui pourraient aide. Et les questions 1 et 3 sont importantes pour moi aussi.

Answer 1

Ce n'est pas un problème de conception de base de données.

Ceci est un problème avec les processus d'utilisation de la conception de base de données. La vraie question que j'ai est de savoir pourquoi les utilisateurs entrent dans les magasins ad-hoc? Je peux penser à des scénarios, mais sans connaître votre situation, il est difficile de deviner.

La solution normale est que la table tblStore est uniquement une table de recherche. Normalement, les utilisateurs n'ont accès qu'aux magasins déjà entrés.

Ensuite, il existe un processus contrôlé pour maintenir la table tblStore d'une manière cohérente. Seuls quelques utilisateurs auraient accès à ce processus.

Bien sûr, comme je l'ai déjà mentionné, ce n'est pas toujours possible, alors vous aurez peut-être besoin d'une solution différente.

MISE À JOUR:

Question n ° 1: Un script de mise à jour est la meilleure approche. La meilleure façon de le faire est d'avoir une copie de la base de données si possible, ou une copie proche sinon, et de tester le script par rapport à ces données. Une fois que vous avez vérifié que le script s'exécute correctement, vous pouvez l'exécuter sur les données réelles.

Si vous avez une intégrité transactionnelle, vous devriez l'utiliser. Utilisez "begin" avant d'exécuter le script et si le nombre d'enregistrements est ce que vous attendez, et tous les autres tests que vous concevez (peut-être aussi scriptés), vous pouvez "valider"

Ne pas taper SQL contre une base de données dynamique . Question n ° 3: Je suggère que votre première ligne d'attaque consiste à créer des processus autour de la création de nouveaux magasins, mais cela peut ne pas être valable dans votre domaine.

Le second est peut-être d'être proactif et d'identifier et d'entrer de nouveaux magasins (si c'est le problème) avant que les utilisateurs sur le terrain ne le fassent. Je ne sais pas si cela fonctionne dans votre scénario. Enfin, si vous avez un script qui a fusionné "store1" en "store2", vous pouvez standardiser cela pour réduire le temps et les erreurs. Vous pourriez même éventuellement construire cela dans un écran d'administration seulement qui fusionne automatiquement les magasins.

C'est tout ce que je peux penser de haut de la tête.