254 karakterlik bir e-posta adresinin geçerli olduğunu biliyorum, ancak araştırdığım uygulamalar varchar (80) ila varchar (80) veya eşdeğeri kullanma eğilimindedir. Örneğin: bu SQL Server önerisi varchar (80) veya bu Oracle örneğini kullanır

Maksimum 254 karakterin tamamını kullanmamak için bir neden var mı? Tanımı gereği bir varchar yalnızca verileri tutmak için gereken kadar depolama alanı kullanmaz mı?

Bu kadar çok uygulamanın olası 254 karakterden daha azını kullanmasına neden olan önemli performans sonuçları / takasları var mı?

Ben her zaman kullandım VARCHAR(320). İşte nedeni. Standart , aşağıdaki sınırlamaları belirler:

• "Yerel kısım" için 64 karakter (kullanıcı adı).
• @Sembol için 1 karakter .
• Etki alanı adı için 255 karakter.

Şimdi, bazı insanlar bundan daha fazlasını desteklemeniz gerektiğini söyleyecek. Bazı kişiler, etki alanı adları için Unicode'u desteklemeniz gerektiğini söyler (yani, geçiş yapmalısınız NVARCHAR). Bu süre zarfında standart değişebilirken (oyunda derim olduğundan beri uzun zaman geçti), şu anda dünyadaki çoğu sunucunun Unicode e-posta adreslerini kabul etmeyeceğinden eminim ve eminim Birçok sunucunun> 320 karakterden oluşan adresler oluşturma ve / veya kabul etme sorunları olacaktır.

Bununla birlikte, eğer isterseniz (ve SQL Server 2008 R2'de Data Compression kullanıyorsanız veya daha iyisi kullanıyorsanız), Unicode sıkıştırmasından faydalanacaksınız, yani gerçekten ihtiyaç duyan karakterler için sadece 2 bayt ceza ödeyeceksiniz. o). Bu şekilde sütununuzu istediğiniz kadar geniş hale getirebilirsiniz ve insanların orada istedikleri kadar uzun çöpleri doldurmalarına izin verebilirsiniz - tıpkı sizin gibi çöpler vermezlerse e-posta almazlar başarısız olursa bir e-posta alırsınız. Sorun, geçersiz önemsiz içeri girmenize izin verirseniz,başa çıkmak zorundayım. Ve ne boyutta olursanız olun - biri 320 karakterlik bir sütuna 400 karakter girmeye çalışacaksa, biri 1024 karakterlik bir sütuna 1025 karakter girmeye çalışacaktır. Herhangi bir mantıklı insanın, sistem sınırlarını açıkça test etmek için kullanmıyorlarsa,> 320 karakterden oluşan bir e-posta adresine sahip olmaları için hiçbir neden yoktur.

Ancak bunun hakkında fikir sormayı bırak - rehberlik için başka uygulamalara bakmayı bırak (bu durumda, referansta bulunduklarıların kendi ev ödevlerini yapmak için zahmet etmemiş olmaları ve sadece sayıları topladıkları, yani, bilirsin) . Standarda doğrudan erişime sahipsiniz - en güncel sürüme başvurduğunuzdan, minimum desteklediğinizden ve standardın üzerinde kaldığınızdan emin olun, böylece özellik değişikliklerine uyum sağlayabilirsiniz.

EDIT sohbetinde ping için @ypercube sayesinde EDIT .

Bir yana, belki de tüm adresi ilk etapta tek bir sütuna dökmek istemezsiniz. Normalleştirme, @hotmail.comçok daha ince bir FK int'nin iyi çalışacağı ve ek değişken uzunluklu sütun ek yüküne sahip olmadığında 15 milyon kez saklamak istemediğinizi önerebilir . Ayrıca, kullanıcı adını normalleştirebilir john.smith@hotmail.comve john.smith@gmail.comortak bir kullanıcı adını paylaşabilirsiniz - birbirlerini tanımıyorlar ancak veritabanınız bunu umursamıyor.

Bunlardan bazılarını burada konuştum:

http://www.mssqltips.com/sqlservertip/2657/storing-email-addresses-more-efficiently-in-sql-server/

http://www.mssqltips.com/sqlservertip/2671/storing-email-addresses-more-efficiently-in-sql-server--part-2/

Bununla birlikte, yukarıdaki 254 karakter sınırına zorluklar getirmektedir, çünkü geçerli bir 255 karakterli alan, geçerli bir 1 karakterli yerel bölümle birleştirildiğinde ne olduğu konusunda fikir birliğine varılmış gibi görünmemektedir. Bu, dünyadaki çoğu sunucu tarafından kabul edilmelidir, ancak bu 254 karakterlik sınırı ihlal ediyor gibi görünmektedir. Yani bir oluşturabilirim Domainsalanı zaman, e-posta adresleri için uzunluğuna yapay olarak düşük kısıtlama var tabloyu olabilir geçerli bir 255 karakterlik URL olarak yeniden kullanılabilir?

Bu kararla ilgili birkaç husus var. Birincisi ve en önemlisi, verilerin uyması gereken gerekli sınırlamaların mevcut ve gelecekteki tahminlerini kullanmaktır. Her dize sütunu veri türünü varchar(1024)yalnızca 32 karakteri aşmaması gereken bir dize depolarken ayarlamak istememesinin bir nedeni var (must anahtar sözcüğüne vurgu yapmalı ).

E-postaların tümünün 255 karakter olacak şekilde değiştirildiği bir tür güvenlik açığına sahipseniz, sayfa bölmeleri üzerinde uzun bir performans etkisi olabilir. Bu sıra dışı görünebilir ve büyük olasılıkla, ancak verilerinizi iş gereksinimine göre boyutlandırmanız gerekir . Veri tabanındaki asırlık kısıtlamaya ve uygulama tartışmalarına benzemeyen, veri türü sınırlamalarının ve izin verilen değerlerin veri katmanında da uygulanması gerektiğine inanıyorum.

Bu beni bir sonraki noktaya yönlendirir. Veri tabanı büyük olasılıkla sadece veri katmanıdır. Uygulama katmanı ne kullanıyor? Örneğin, bir e-posta adresi için yalnızca 80 karakter girebileceğiniz bir uygulamanız varsa, neden veri türünün daha büyük olmasını istersiniz? İşletmenin iki soruyu yanıtlaması gerekiyor:

1. Ne olabilir ?
2. Ne olmalı ?

Ancak o zaman cevabınızı alacaksınız.

Tanımı gereği bir varchar yalnızca verileri tutmak için gereken kadar depolama alanı kullanmaz mı?

Evet ve hayır. Uzunluğunu kaydetmek için değişken uzunluk verisi için bir çeşit mahsup olacak.

RFC 5321 (mevcut SMTP spesifikasyonu, eski RFC2821):

Bir kullanıcı adının veya başka bir yerel bölümün maksimum toplam uzunluğu 64 sekizdir. Bir alan adının veya numarasının maksimum toplam uzunluğu 255

Bu yüzden 64 + 255 + @ işareti VARCHAR (320) anlamına gelir. Muhtemelen bu kadar bilgiye asla ihtiyacınız olmayacak, ancak durumda olması güvenli.

Herhangi bir VARCHAR varyasyonu yalnızca veri bloğunda gerektiği kadar boşluk kullanır. Uzunluğu depolamak için ek baytlar, bunun yerine sabit uzunluklu bir CHAR kullanılarak harcanacak alana kıyasla önemsizdir.

Bir VARCHAR sütun uzunluğu gerçekten "maksimum uzunluk" olduğundan, her koşulda mümkün olan maksimum uzunluktan daha büyük ayarlanmalıdır. Yalnızca her satırın ihtiyaç duyduğu kadar boşluk kullanılacaktır. Uygulama programları daha sonra kaydırma alanlarıyla veya tipik değerlere dayalı olarak anlamlı olanlarla tasarlanmalıdır.

Bir veritabanı tasarımı, boyut olarak zor sınırları belirleyen fiziksel bir kağıt parçası gibidir. Kağıt sayfa büyütülemez. Bu analojide, uygulama programı sayfada basılan bir form gibidir. Formda ne kadar veri tutabileceğimizi ayarlamak için yapılabilecek çok şey var.

Bir VARCHAR boyutunu artırma komutu basit görünebilir ve anında küçük bir masa üzerinde çalışabilir, ancak bunu binlerce veya daha fazla satır içeren bir masada yapmak büyük olasılıkla tüm veri ve indeks bloklarını yenilerken bir tür veri tabanı kesimi gerektirecektir. Bunun bir yolu, her şeyi daha büyük sütunlarla yeni bir tabloya kopyalamak. Hangi teknik kullanılırsa kullanılsın, çok kıllı bir anlaşma. Bu nedenle, bir üretim tablosu yüklendikten sonra VARCHAR sütun büyüklüğünü büyük oranda değişken değildir.

Zaten burada mükemmel cevaplar bir yorum olarak:

Öncelikle, alanı olduğu gibi oluşturduysanız ve varchar(240)daha sonra daha uzun bir alana değiştirmek istiyorsanız varchar(320), bu değişikliğin elbette veritabanı ürününüze bağlı olarak veritabanı sunucusunda önemsiz bir işlem olması gerektiğini söyleyin .

alter table Schema.Object alter column EmailAddress varchar(320) ;

İkincisi, ortalama satır boyutuna ve sayfa boyutuna bağlı olarak, varchar(320)bunun yerine kullanmak varchar(240), ayrılan sayfaların sayısını değiştiremez (disk alanı gerçekten tablo tarafından kaplanır).

Üçüncüsü, yukarıdaki kişiler bir e-posta adresini doğrulamaktan bahsetti. Bir e-posta adresini doğrulamak için tek bir kesin yol olduğunu ve buna bir e-posta göndermek olduğunu iddia ediyorum. :-)

VARCHAR, e-postalar uzunluğuna göre değişiklik gösterdiğinden, e-posta adresleri için kullanılacak en iyi veri türüdür. NVARCHAR da bir alternatiftir, ancak yalnızca e-posta adresi genişletilmiş karakterler içeriyorsa ve VARCHAR'a kıyasla iki kat depolama alanı gerektirdiğini unutmayın.

Benim çevremde, karşılaştığım en uzun süre 60-70 karakter uzunluğunda olduğu için varchar (70) kullanıyoruz, ancak şirketinizin müşteri tabanına da bağlı. Ayrıca, bir not olarak, e-posta adreslerinin geçerliliği için yerinde bazı E-posta doğrulama kontrolleri olduğundan emin olun. Kontrol kısıtlamaları veya CHARINDEX kullanın.

SQL kullanarak DOMAIN

Bir Enterprise Database sunucusu kullanıyorsanız, bir e-posta adresini bir DOMAINgeçerlilik düzeyi gibi saklamak için bir yol bulunmalıdır . Etki alanları SQL şartnamesinde belirtilmiştir.

Etki alanı, bir veri türünün belirtilebileceği belirli yerlerdeki veri türüne alternatif olarak belirtilebilen adlandırılmış bir kullanıcı tanımlı nesnedir. Bir etki alanı, bir veri türü, muhtemelen varsayılan bir seçenek ve sıfır veya daha fazla (etki alanı) kısıtlamadan oluşur.

Örneğin, özgür ve açık kaynaklı PostgreSQL bunu destekler, şartnamenin uygulanmasındaki herhangi bir kısıtlamayı engellerse, sütunda geçerli bir e-posta bulunur. Mesela ..

• DOMAINHTML5 e-posta belirtimi üzerinden bir özel oluşturun .
• Veya, RFC822, RFC2822, RFC5322 e-posta özelliklerine göre.
• DOMAINSunucuyu, kontrol sırasında MX kaydı için kontrol eden bir özel oluşturun .

Bu seçenekleri PostgreSQL'e özgü olan bu cevapta değerlendiriyorum.