時々、私はユーザーの電子メールが重複していることに気づきます。一意性をチェックするモデル検証（アプリレベル）でさえも。私はこれが並行性の問題に関係していると考えています。電子メールをダウンケースとして保存する際に問題がありますか？
私はこれに対処するためにdbレベルにインデックスを追加することに決めました。
とにかくインデックスが低いのはおそらく分かりやすいでしょう。
電子メールがアプリケーションレベルで低下していることを保証しても、データベースは一貫性のより強い保証を提供します。
これは決して重要ではないかもしれませんが、DBを強制することで傷つけることもありません。
大文字は決してアプリ側から入力されることはないが、アプリは他のソースからデータベースに入るデータを制御することができず、そのすべてのコード開発者のエラー、メンテナンスコストなどの傾向がある
私もuserモデルでこのコードブロックでこのロジックを結合しました
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
：[email protected]は次のように書き換えますが保証
def email=(value)
write_attribute :email, value.downcase
end
[email protected]（アプリレベル）
ほとんどのケースで、大文字と小文字を区別する電子メールサーバーがあることを示すAre email addresses case sensitive?のポインタから、RFCのオンラインを読んでいます。
今日でも私は電子メールを送信します。私はほとんどケーシングに気を取らない。実際には、電子メールをダウンケースとして出力します。電子メールは引き続き配信されます。
RFCは非常に考慮すべき点ですか？すなわち、ユーザが[email protected]を入力した場合、[email protected]として電子メールが登録されます。これは電子メールの「配信可能性」に影響を及ぼしますか？
そうでない場合は、他にどのような懸念事項を考慮する必要がありますか？
実際の答えではなく、ちょうどハックの提案：「正規化された」電子メール（「normalized_email」のような）を保存するための別の列もありません。まれに、まれに同一のメールアドレスを持つ2人のユーザーがいる場合は、他のメールを使用するか、別の方法でこれを処理するかのどちらかを要求できます。 –
2番目の列を持つことも私が考えている提案です。しかし、この検討の前に、小文字の電子メールに関する提案が推奨されるアプローチであるかどうかを知りたい –