5
我不時注意到用戶的電子郵件是重複的。即使使用模型驗證（應用程序級別）來檢查唯一性。我懷疑這與併發問題有關。存儲電子郵件時存在任何問題？
我已決定在db級別上添加一個索引來解決這個問題。
無論如何，較低的指數可能是明智的。
即使我們保證在應用程序級別降低電子郵件。數據庫提供了一致性的更強保證。
它可能永遠不會有問題，但有DB強制它也不能傷害。
我可以放入很多額外的安全措施，以最大限度地提高從應用程序端沒有放入大寫字符的可能性，但應用程序仍然無法控制從其他來源進入數據庫的數據，並且所有代碼容易出現錯誤的顯影劑，維護成本等
class CreateUniqueIndexForUserEmails < ActiveRecord::Migration
def up
remove_index :users, :email
execute <<-SQL
CREATE UNIQUE INDEX index_users_on_lower_email ON users (LOWER(email));
SQL
end
def down
execute <<-SQL
DROP INDEX index_users_on_lower_email;
SQL
add_index :users, :email
end
end
我還在user模型耦合這個邏輯與代碼塊：
def email=(value)
write_attribute :email, value.downcase
end
確保[email protected]被重寫爲[email protected]（在應用程序級別）。
我已經在線閱讀了一個RFC，主要來自Are email addresses case sensitive?的指針，這些指針指示某些電子郵件服務器關心區分大小寫。
即使如此，當我今天發送電子郵件。我很難不介入套管。實際上，我將這封電子郵件輸入爲簡體中文。電子郵件仍然交付。
RFC是否需要高度考慮？即如果用戶輸入[email protected]，則應用程序將電子郵件登記爲[email protected]。這會對電子郵件「產能」產生什麼影響嗎？
如果不是，我應該考慮哪些其他問題？
不是一個真正的答案，只是一個黑客的建議：爲什麼不有一個單獨的列來存儲「正常」電子郵件（如'normalized_email'），這也應該是唯一的？我的意思是，在極少數情況下，案件的確很重要，而且有兩個用戶使用其他方式相同的電子郵件，您可以要求他們中的一個使用其他電子郵件或以其他方式處理此問題。 –
有一個第二列是我也考慮過的建議。但在此考慮之前，我想知道關於低層電子郵件的建議是否是推薦的方法 –