Названия предприятий, которые разные люди называют по-разному

Question

У меня есть эта таблица

tblStore

с этими полями

storeID (autonumber)  
storeName  
locationOrBranch

и эта таблица

tblPurchased

с этими полями

purchasedID  
storeID (foreign key)  
itemDesc

В случае магазинов, имеющих более одного местоположения, возникает проблема, когда два человека по неосторожности вводят одно и то же местоположение магазина по-разному. Например, возьмите Гаррисберг Шеврон. По некоторым квитанциям он называет себя «Гаррисберг Шеврон», некоторые просто называют «Шеврон» наверху, а под ним - «Гаррисберг». Один человек может ввести его в tblStore как storeName Chevron, местоположение или филиал Harrisburg. Person2 может указать его как storeName Harrisburg Chevron, местонахождение Orchranch Harrisburg. Что делает это плохо, так это то, что бизнес зовут Гаррисберг Шеврон. Кажется, трудно выработать правило (которое по понятным причинам охватывало бы все будущие возможности для этой ошибки), чтобы люди не делали этого в будущем.

Вопрос 1) Я думаю, что когда экземпляры найдены, запрос на обновление, чтобы изменить все записи с одного пути на другой, является лучшим способом исправить это. Это правильно?

Вопросы 2) Как лучше всего изначально настроить базу данных, чтобы избежать этого?

Вопрос 3) Что я могу сделать, чтобы облегчить будущие исправления после факта, когда это произойдет?

Спасибо.

edit : Я понимаю, что лучшая деловая практика - это идеальная профилактика, но для вопроса 2 я ищу любые советы или хитрости, которые используют люди, которые могут помочь . И вопросы 1 и 3 тоже важны для меня.

Answer 1

Это не проблема проектирования базы данных.

Это проблема процессов, связанных с использованием дизайна базы данных.

Реальный вопрос, который у меня возникает, - это почему пользователи заходят в магазины ad-hoc? Я могу думать о сценариях, но, не зная вашей ситуации, трудно угадать.

Нормальным решением является то, что таблица tblStore является только справочной таблицей. Обычно пользователи имеют доступ только к тем магазинам, которые уже были введены.

Затем существует контролируемый процесс для согласованного ведения таблицы tblStore. Только несколько пользователей будут иметь доступ к этому процессу.

Конечно, как я упоминал выше, это не всегда возможно, поэтому вам может потребоваться другое решение.

UPDATE:

Вопрос № 1: наилучшим подходом является сценарий обновления. Лучший способ сделать это - иметь копию базы данных, если это возможно, или закрытую копию, если нет, и проверить сценарий на соответствие этим данным. Убедившись, что скрипт работает правильно, вы можете запустить его на реальных данных.

Если у вас есть целостность транзакции, вы должны использовать это. Используйте «начало» перед запуском сценария, и если количество записей соответствует ожидаемому, а также любым другим тестам, которые вы разработали (возможно, также в сценариях), то вы можете «зафиксировать»

Не вводить SQL против живой БД.

Вопрос № 3: Я предлагаю, чтобы ваша первая линия атаки заключалась в создании процессов вокруг создания новых магазинов, но это не может быть в ваших интересах.

Второе - это проактивность, идентификация и ввод новых магазинов (если это проблема) до того, как это понадобится пользователям на местах. Я не знаю, работает ли это в вашем сценарии.

Наконец, если у вас есть скрипт, который объединяет «store1» с «store2», вы можете стандартизировать его, чтобы сократить время и ошибки. Вы даже можете встроить это в экран только администратора, который автоматизирует объединение магазинов.

Это все, что я могу думать о макушке головы.