我有这张桌子
tblStore
使用这些字段
storeID (autonumber)
storeName
locationOrBranch
和这张表
tblPurchased
使用这些字段
purchasedID
storeID (foreign key)
itemDesc
对于具有多个位置的商店，当两个人无意中以不同方式键入同一商店位置时会出现问题。例如，哈里斯堡雪佛龙。在一些收据上它称自己为哈里斯堡雪佛龙，有些人只是说雪佛龙在顶部，而在此之下，哈里斯堡。一个人可以将它作为storeName Chevron，locationoOrBranch Harrisburg键入tblStore。 Person2可以将其作为商店名称Harrisburg Chevron，locationOrBranch Harrisburg。造成这种情况的原因是该公司的名称是Harrisburg Chevron。似乎很难制定一个规则（这可以理解地涵盖了此错误的所有未来机会），以防止人们在将来这样做。
问题1）我正在考虑找到实例，更新查询将所有记录从一种方式更改为另一种方式是修复它的最佳方法。这是对的吗？
问题2）最初设置数据库以避免这种情况的最佳方法是什么？
问题3）如果发生这种情况，我可以做些什么来使未来事后修正更容易？
感谢。
编辑：我确实理解更好的商业行为是理想的预防措施，但对于问题2，我正在寻找人们使用的任何提示或技巧帮助 。问题1和问题3对我也很重要。
答案 0 :(得分：0)
这不是数据库设计问题。
这是围绕使用数据库设计的过程的一个问题。
我真正的问题是为什么用户会临时进入商店？我可以想到场景，但不知道你的情况很难猜测。
正常的解决方案是tblStore表只是一个查找表。通常，用户只能访问已经输入的商店。
然后有一个受控过程以一致的方式维护tblStore表。只有少数用户可以访问此过程。
当然，正如我上面所提到的，这并不总是可行的，所以你可能需要一个不同的解决方案。
更新：
问题＃1：更新脚本是最好的方法。执行此操作的最佳方法是尽可能获取数据库的副本，如果不是，则获取密切副本，并根据此数据测试脚本。一旦确保脚本正确运行，就可以针对实际数据运行它。
如果您有事务完整性，则应该使用它。在运行脚本之前使用“begin”，如果记录的数量是您所期望的，以及您设计的任何其他测试（也许还有脚本），那么您可以“提交”
请勿针对实时数据库键入SQL。
问题3：我建议你的第一道攻击线是围绕新店铺的创建创建流程，但这可能不是你的范围。
第二种可能是在主场用户需要这样做之前主动识别并进入新商店（如果这是问题）。我不知道这是否适合您的情况。
最后，如果您有一个将“store1”合并到“store2”的脚本，您可以将其标准化，以减少时间和错误。您甚至可以将其构建为自动合并商店的仅限管理员的屏幕。
这就是我能想到的全部。