我正在構建允許用戶提交事件的Rails 3.1應用程序。比賽場地之一是比賽場地。在創建/編輯表單中，venue_name字段具有自動完成功能，因此它顯示具有相似名稱的場地，但用戶可以輸入任何名稱。從自動填充表單修復Rails應用中的重複記錄
提交表單時，我在將場地附加到事件模型時使用了find_or_create_by_name。
我這樣做是因爲我們無法保存完整的場地列表，我也不想阻止人們提交活動，因爲場地不在列表中。
問題是，很可能我們會像「Venue Name」和「The Venue Name」或任何其他可能性一樣隨時間重複。
我在想，我可能只是需要創建一個管理工具，允許管理員查看最近的場地，如果他/她認爲他們是重複搜索/選擇主記錄並將重複記錄的關聯複製過來到主記錄並且一旦成功刪除重複記錄。
這是一個很好的方法嗎？就數據操作而言，最好在交易中處理這個問題？最好是將這種功能添加到某種工具類中 - 或直接在Venue模型中添加？
感謝您的時間。
如果我打算將這樣的系統組合起來，我可能會嘗試找到一個可以與每個場所關聯的唯一標識符 - 可能是地址或電話號碼？
因此，如果我有一個電話號碼503-555-1212的「俱樂部」，並且有人試圖用電話號碼503-555-1212輸入一個名爲「俱樂部」的新場地，我可能會帶他們去一個插頁式廣告頁面，我問他們「你的意思是這個位置？」
除此之外，我可能會首先要求輸入電話號碼或地址，然後列出可能的匹配列表並創建一個新場地。
否則，您在管理員級別引入了很多潛在的錯誤，並且遇到了可伸縮性問題。如果您的管理員每個月都要查看10個條目，也許並不那麼糟糕 - 但是如果您的應用程序啓動並且該數量達到1000，那麼該速度就變得難以管理！
感謝您的回答。現在，我只是要求會場名稱 - 在活動層面沒有其他數據。這主要是因爲我希望他們應該在大多數情況下找到他們正在尋找的場地。這個應用程序的可伸縮性問題會減少，因爲這些事件都在一箇中等城市。我可以添加一張支票，但是如果他們進入一個新的場地，而不是從自動提示中選擇一個輸入電話號碼並從中進行檢查。這當然可以減少這個問題，但我懷疑它會完全消除它。 – someoneinomaha 2012-01-13 03:40:44
我明白你來自哪裏。儘管如此，我認爲我仍然主張增加某種事件級別的檢查，作爲防止用戶「創造力」的保護措施。 :)任何時候你有用戶輸入驅動的關鍵數據，都值得跳過一兩圈，儘可能地把所有的東西都放進槽中。在這一天結束時，我認爲在這裏只有兩種解決方案：限制輸入的方式，或在之後解決問題。事後行政清理雖然對於邊緣案件可能是必要的，但可能不應該成爲日常業務流程的一部分。 – 2012-01-13 08:42:21
我認爲你是在正確的軌道上。我會以類似的方式去做。 – phoet 2012-01-12 21:39:10