11

電子メール アドレスの場合、SQL Server の列にどのくらいのスペースを与える必要がありますか。

ウィキペディアで次の定義を見つけました。

http://en.wikipedia.org/wiki/Email_address

電子メール アドレスの形式は local-part@domain であり、local-part は最大 64 文字、ドメイン名は最大 253 文字ですが、転送パスまたは逆パスの最大 256 文字の長さが全体を制限します。メールアドレスは254文字以内

そしてこれ：

http://askville.amazon.com/maximum-length-allowed-email-address/AnswerViewer.do?requestId=1166932

したがって、今のところ、電子メール アドレスに許可されている合計文字数は、64 (ローカル部分) + 1 ("@" 記号) + 255 (ドメイン部分) = 320 です。

将来的には、ローカル部分の制限を 128 文字に増やす可能性があります。合計で 384 文字になります。

何かご意見は？

4

2 に答える 2

14

後者の計算に基づいて、私は常に320を使用しました。人々がそれを悪用してそこにがらくたを詰め込まない限り、それ以上を許可するのに何も費用はかかりません*。正当に長い電子メールアドレスを持っているとイライラするユーザーがいるため、許可するコストが低くなる可能性があります。今度は、戻ってスキーマ、コード、パラメーターなどを更新する必要があります。 （電子メールサービスプロバイダー）では、私が自然に出会った最長の電子メールアドレスは約120文字でした。そして、彼らがニヤリと長い電子メールアドレスを作成していることは明らかでした。

*厳密には当てはまりません。メモリ付与の見積もりは、さまざまな幅の列が半分入力されているという仮定に基づいているため、同じデータを格納する幅の広い列は、特定のクエリのパフォーマンス特性が大きく異なる可能性があります。

NVARCHARそして、メールアドレスが必要かどうかを議論しました。Unicode文字を使用した電子メールアドレスはまだ見つかりません。標準でサポートされていることはわかっていますが、既存のシステムの多くはサポートしていないため、それがあなたの電子メールアドレスであるとしたらかなりイライラします。

コストがスペースの2倍になるのは事実ですがNVARCHAR、SQL Server 2008 R2では、基本的に列内のすべての非Unicode文字をASCIIとして扱うUnicode圧縮の恩恵を受けることができるため、NVARCHAR余分なバイトを取り戻すことができます。もちろん、圧縮はEnterprise+でのみ利用可能です...

必要なスペースを削減するもう1つの方法は、監視対象のすべてのドメイン名に中央ルックアップテーブルを使用し、ユーザーとともに保存LocalPartしDomainID、一意のドメイン名を1回だけ保存することです。はい、これはプログラミングをより面倒にしますが、80,000のhotmail.comアドレスがある場合、コストは80,000 x 11バイト（圧縮の場合はそれ以下）ではなく、80,0000x4バイトになります。ストレージまたはI/OがCPUではなくボトルネックである場合、これは間違いなく調査する価値のあるオプションです。

私はこれについてここに書いた：

于 2012-02-15T14:53:19.893 に答える
0

VARCHAR（320）は、ASCIIベースのドメイン名と電子メールアドレスの通常の制限だと思います。しかし、Unicodeドメイン名がすぐに表示されるようになりませんか？

http://en.wikipedia.org/wiki/Internationalized_domain_name

たぶんNVARCHAR（320）は私たちが使い始めるべきものですか？

于 2012-02-15T14:58:17.397 に答える