it-swarm-eu.dev

V jakém datovém typu bych měl e-mailovou adresu ukládat do databáze?

Rozumím, že e-mailová adresa s 254 znaky je platná, ale implementace, které jsem zkoumal, mají tendenci používat varchar (60) k varchar (80) nebo ekvivalent. Například: toto doporučení serveru SQL používá varchar (80) nebo tento příklad Oracle

Existuje důvod, proč nepoužívat maximum 254 znaků? Nepoužívá varchar podle definice pouze tolik úložiště, kolik je potřeba k uložení dat?

Existují významné důsledky/kompromisy ve výkonu, které způsobují, že tolik implementací používá méně než plných 254 možných znaků?

47
Thronk

Vždy jsem používal VARCHAR(320). Tady je důvod. Standard diktuje následující omezení:

  • 64 znaků pro "místní část" (uživatelské jméno).
  • 1 znak pro symbol @.
  • 255 znaků pro název domény.

Nyní někteří lidé řeknou, že musíte podporovat více než to. Někteří lidé také řeknou, že je třeba podporovat Unicode pro doménová jména (což znamená, že musíte přepnout na NVARCHAR). Zatímco se standard může mezitím změnit (je to už dlouho, co jsem měl ve hře kůži), jsem si docela jistý, že v tuto chvíli většina serverů na světě nepřijme e-mailové adresy Unicode, a jsem si jistý, mnoho serverů bude mít problémy s vytvářením a/nebo přijímáním adres s> 320 znaky.

To znamená, že se můžete nyní připravit na to nejhorší (a pokud používáte kompresi dat v SQL Server 2008 R2 nebo lepší, budete mít prospěch z komprese Unicode, což znamená, že zaplatíte 2 bajtový trest za znaky, které skutečně potřebují to). Tímto způsobem si můžete vytvořit svůj sloupec tak široký, jak chcete, a můžete nechat lidi, aby tam nacpali příliš dlouhý odpad, který chtějí - nedostanou e-mail, pokud vám dají nevyžádanou poštu tak, jako by to nechtěli. v případě selhání vložení obdržíte e-mail. Problém je, pokud necháte neplatné nevyžádané, vy se s tím vypořádat. A bez ohledu na to, jakou velikost to uděláte - pokud se někdo pokusí nacpat 400 znaků do sloupce 320 znaků, někdo se pokusí nacpat 1025 znaků do sloupce 1024 znaků. Neexistuje žádný důvod, proč by rozumná osoba měla mít e-mailovou adresu> 320 znaků, pokud ji nepoužívá k výslovnému testování systémových hranic.

Přestaňte však o to žádat názory - a přestat se dívat na další implementace jako vodítko (v tomto případě se tak stane, že ty, na které jste odkazovali, se neobtěžovaly dělat své domácí úkoly a pouze vybraly čísla) z jejich, dobře, víte). Máte přímý přístup ke standard - ujistěte se, že jste konzultovali nejnovější verzi, podporovali to minimálně a zůstali na špičce standardu, abyste se mohli přizpůsobit změnám specifikací.


[~ # ~] editovat [~ # ~] díky @ypercube za ping v chatu.

Kromě toho asi nechcete nejprve vypsat celou adresu do jediného sloupce. Normalizace by mohla naznačovat, že nechcete ukládat @hotmail.com 15 milionůkrát, když by mnohem hubenější FK int fungovalo dobře a nemělo by další režii sloupců s proměnnou délkou. Můžete také normalizovat uživatelské jméno, protože [email protected] A [email protected] Sdílejí společné uživatelské jméno - oni se navzájem neznají, ale vaše databáze se o to nestará.

Zde jsem o něčem mluvil:

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

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

To však představuje výzvu k limitu 254 znaků výše, protože se nezdá, že existuje shoda ohledně toho, co se stane, když je platná doména 255 znaků kombinována s platným místním dílem o 1 znaku. To by mělo být akceptováno většinou serverů po celém světě, ale zdá se, že porušuje tento limit 254 znaků. Vytvoříte tedy tabulku Domains, která má uměle nižší omezení délky pro e-mailové adresy, když je doména mohla znovu použita jako platná adresa 255 znaků ?

49
Aaron Bertrand

S tímto rozhodnutím existuje několik úvah. V první řadě je použít současné a budoucí předpovědi nezbytných omezení, kterým budou data muset vyhovovat. Existuje důvod, proč nechcete nastavit každý typ dat sloupce řetězce na varchar(1024), když právě ukládáte řetězec, který neměl by přesahovat 32 znaků (důraz na klíčové slovo by).

Pokud máte nějaký druh chyby zabezpečení, kde jsou všechny e-maily upraveny tak, aby se staly 255 znaky, mohlo by to mít dlouhý dopad na rozdělení stránek. To se může zdát neobvyklé, a je to s největší pravděpodobností, ale musíte přizpůsobit své údaje obchodním požadavkům. Stejně jako věkové omezení v debatě o databázi a aplikacích jsem pevně přesvědčen, že omezení datového typu a přípustné hodnoty by měly být prosazovány také na datové úrovni.

Což mě vede k mému dalšímu bodu. Databáze je pravděpodobně pouze datová vrstva. Co využívá aplikační vrstva? Například, pokud máte aplikaci, ve které můžete zadat pouze 80 znaků pro e-mailovou adresu, proč byste chtěli, aby byl typ dat větší? Podnik musí odpovědět na dvě otázky:

  1. Co může to je?
  2. Co mělo by to by mělo být?

Teprve potom budete mít odpověď.

Nepoužívá varchar podle definice pouze tolik úložiště, kolik je potřeba k uložení dat?

Ano i ne. Bude existovat jakýsi offset pro data proměnné délky k zaznamenání jejich délky.

5
Thomas Stringer

Stavy RFC 5321 (aktuální specifikace SMTP, zastaralé RFC2821):

Maximální celková délka uživatelského jména nebo jiné místní části je 64 oktetů. Maximální celková délka názvu domény nebo čísla je 255 oktetů

Znaménko 64 + 255 + @ tedy znamená VARCHAR (320). Pravděpodobně to nikdy nebudete tolik potřebovat, ale je bezpečné mít to pro jistotu.

3
avakharia

Jakákoli variace VARCHAR využívá pouze tolik místa v datovém bloku, kolik je potřeba. Další bajty pro uložení délky jsou triviální ve srovnání s prostorem, který by byl zbytečně použit místo pevné CHAR.

Protože délka sloupce VARCHAR je skutečně „maximální délka“, měla by být za žádných okolností nastavena větší, než je maximální délka. Bude použito pouze tolik místa, kolik potřebuje každý řádek. Aplikační programy by pak měly být navrženy s rolovacími poli nebo podle toho, co má smysl, na základě typických hodnot.

Návrh databáze je jako fyzický kus papíru v tom, že stanoví tvrdé limity co do velikosti. Papírovou stránku nelze zvětšit. V této analogii je aplikační program jako formulář vytištěný na stránce. Existuje mnoho toho, co lze udělat pro úpravu toho, kolik dat můžeme ve formuláři uchovávat.

Ačkoli příkaz ke zvětšení velikosti VARCHARu může vypadat jednoduše a okamžitě spustit na malé tabulce, tak u tabulky s tisíci řádků nebo více bude pravděpodobně vyžadovat nějaký druh databázového klidového stavu při regeneraci všech datových a indexových bloků. Jedním ze způsobů je zkopírovat vše do nové tabulky s většími sloupci. Ať už je použita jakákoli technika, jedná se o velmi velký vlas. Po načtení produkční tabulky byste tedy měli považovat velikost sloupce VARCHAR za značně neměnnou.

1
DocSalvager

Jako komentář k vynikajícím odpovědím již zde:

Nejprve, pokud jste pole vytvořili jako varchar(240) a chcete jej později změnit na delší pole, řekněme varchar(320), měla by být tato změna triviální operací na databázovém serveru - v závislosti na , samozřejmě, na vašem databázovém produktu.

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

Za druhé, v závislosti na průměrné velikosti řádku a velikosti stránky, použití varchar(320) namísto varchar(240) nemusí změnit počet přidělených stránek (místo na disku skutečně zabrané tabulkou).

Za třetí, někdo výše mluvil o ověření e-mailové adresy. Tvrdím, že existuje pouze jeden jistý způsob, jak ověřit e-mailovou adresu, a to poslat e-mail na ni. :-)

1

Pomocí SQL DOMAIN

Používáte-li server Enterprise Database, mělo by se určitým způsobem uložit e-mailová adresa jako DOMAIN s určitou úrovní platnosti. Domény jsou specifikovány ve specifikaci SQL

Doména je pojmenovaný objekt definovaný uživatelem, který lze určit jako alternativu k datovému typu na určitých místech, kde lze specifikovat datový typ. Doména se skládá z datového typu, možná výchozí možnosti a nulových nebo více (doménových) omezení.

Například to podporuje bezplatný a otevřený zdroj PostgreSQL, a to s výjimkou omezení při implementaci specifikace, samotný sloupec obsahuje platný e-mail. Můžete například ..

  • Vytvořte si vlastní DOMAIN přes e-mail s HTML5.
  • Nebo přes RFC822, RFC2822, RFC5322 e-mail.
  • Vytvořte vlastní DOMAIN, který v okamžiku kontroly zkontroluje server pro záznam MX.

Vyhodnocuji tyto možnosti v tato odpověď je specifická pro PostgreSQL

0
Evan Carroll

VARCHAR je nejlepší datový typ, který se používá pro e-mailové adresy, protože e-maily se velmi liší délkou. NVARCHAR je také alternativou, ale doporučuji ji použít pouze v případě, že e-mailová adresa obsahuje rozšířené znaky a mějte na paměti, že ve srovnání s VARCHARem vyžaduje dvojnásobné množství úložného prostoru.

V mém prostředí používáme varchar (70), protože ty nejdelší, s nimiž jsem se setkal, jsou úzce 60–70 znaků, ale záleží také na zákaznické základně vaší společnosti. Jako vedlejší poznámku se také ujistěte, že máte nějaké ověřovací e-mailové kontroly platné pro platnost e-mailových adres .. jako je použití kontrolních omezení nebo CHARINDEX

0
Kin Shah