it-swarm-eu.dev

Doporučené postupy v oblastech běžných osob (jméno, e-mail, adresa, pohlaví atd.)

Jaké jsou nejčastější doporučené postupy týkající se délky a typu dat v běžných polích, jako jsou:

  • Jméno
  • Příjmení
  • Adresa
  • E-mailem
  • Sex
  • Stát
  • Město
  • Země
  • Telefonní číslo

atd....

44
Snow_Mac

Chtěl bych být velmi podezřelý z jakéhokoli souboru všeobecných osvědčených postupů, protože pro většinu z těchto oblastí je ďábel v detailech. To, že informace jsou relativně běžné, neznamená, že vaše aplikace data používá přesně stejným způsobem, jakým je používají jiné aplikace. To znamená, že váš datový model může být poněkud odlišný.

  • Jméno a příjmení: Proč zachycujete jméno? Pokud máte povinnost zachytit celé jméno osoby (tj. Připravujete právní doklady nebo rodné listy), pravděpodobně budete chtít lidem poskytnout více místa, než byste zadali, kdybyste jen požadovali jméno osoby, takže mít něco, čemu je můžete ve své nové webové aplikaci nazvat.
  • Adresa: Co budete dělat s adresou? Jaké adresy ukládáte? Pokud ukládáte adresu nemovitosti ve Spojených státech amerických, na které vytváříte hypotéku, pravděpodobně se budete velmi zajímat o získání plně standardizované adresy. V takovém případě bude datový model pravděpodobně chtít velmi pečlivě sledovat jakoukoli vaši adresu standardizační nástroj se vrací. Pokud chcete, aby lidé mohli zadat adresu pro dodání produktu, postačí pár řádků pro volný text. Délka řádků může záviset na požadavcích následných procesů, které dělají věci jako tisk štítků s adresou.
  • Stav: Za předpokladu, že můžete identifikovat platné hodnoty stavu, má pravděpodobně smysl vytvořit tabulku STATE a vytvořit vztah cizího klíče mezi tabulkami STATE a ADDRESS. Schopnost identifikovat platné hodnoty však znamená, že omezujete sadu platných adres alespoň na konkrétní sadu zemí. To je v pořádku pro mnoho webů, ale pak musíte udělat trochu práce na podporu nové země.
  • Město: Pokud pracujete s údaji, kde jsou potenciálně zavedeny předpisy na úrovni města (tj. Kde existují různé druhy daňových sazeb, které se uplatňují na základě města), možná budete chtít zacházet s nimi podobně jako stát a mít Tabulka CITY s platnými městy a vztah cizího klíče mezi tabulkami CITY a ADDRESS. Na druhou stranu, pokud se jen snažíte doručit produkt a nestaráte se o to, zda máte v tabulce různé verze stejného města, postačuje nechat uživatele zadávat text zdarma. Samozřejmě, pokud ukládáte cizí klíče, budete mít spoustu práce, abyste se ujistili, že máte všechny platné hodnoty. Existují však produkty, u nichž jde pouze o to, že společnost již tuto práci provedla (tj. Databáze daně z obratu).
  • Telefon: Co děláte s telefonními čísly a proč? Některé aplikace budou chtít přijímat telefonní čísla v jakémkoli formátu, ve kterém se uživatel rozhodne je zadat, a zachovat toto formátování pro všechny následné dotazy. To by bylo běžné, pokud navrhujete osobní adresář, ve kterém mají uživatelé vlastní preference pro ukládání a zobrazování telefonních čísel. Jiné aplikace by chtěly ignorovat zadané formátování, extrahovat pouze číselné znaky a poté formátovat data při načítání tak, aby všechna telefonní čísla měla podobné formátování. Pokud zajišťujete podniky, možná budete chtít, aby uživatelé zadali rozšíření do samostatného pole. Pokud se pokoušíte podporovat odchozí volání, možná budete chtít uložit předvolbu a kód země do samostatných sloupců, protože budete chtít mít jistotu, že máte okna specifická pro časové pásmo pro volání lidí v různých předvolbách ( volání na někoho ve východním časovém pásmu v 10 hodin ráno bude mnohem lepší než uskutečnění stejného hovoru s někým v tichomořském časovém pásmu, kde je 7:00).
  • Pohlaví: Pro mnoho aplikací je naprosto rozumné uložit kód pohlaví („M“ nebo „F“) v tabulce. Na druhou stranu existují případy, kdy budete chtít další možnosti (Jiné, Intersex, Transgendered) nebo kde je třeba uložit něco jako pohlaví při narození a aktuální pohlaví.
50
Justin Cave

Můžete také hádat na základě ukázkových dat a očekávaného publika. Záleží na vaší poloze.

Několik poznámek:

Adresy:

Názvy:

Telefonní číslo: Mezinárodní kód, délka, mobilní vs dům, povolit mobilní jako jediné číslo

24
gbn

Kromě skvělých odpovědí výše nezapomeňte přijímat znaky Unicode. To, že jste v USA, neznamená, že do svých sloupců nechcete přijímat cizí postavy.

To znamená, že obvykle doporučuji 50 znaků pro jména. Číslo 320 by mělo být více než dost pro e-mailovou adresu (pro jistotu si můžete zkontrolovat standard ANSI). Pro chybu adresy na straně opatrnosti s 255 znaky. I když pravděpodobně nikdy nebudete potřebovat tak velkou adresu, můžete zahrnout řádky C/O a podobné. Město by mělo být docela velké, tam jsou nějaké docela dlouhé názvy měst. Pro stát jděte s dětským stolkem, stejně jako se zemí. U PSČ nezapomeňte na mezinárodní poštovní směrovací čísla, která jsou delší než americké PSČ. Jen proto, že nepodporujete mezinárodní, můžete být stále. Existuje spousta amerických občanů, kteří žijí v různých zemích, včetně vojenských lidí.

Nezapomeňte, že stát by měl být volitelný, protože mnoho zemí nemá státy.

10
mrdenny

Můj zadek se bolí z toho, že sedí na plotě, takže budu jen vyhodit pár odpovědí a doufám, že nebudu volen do zapomnění. Nabídněte konstruktivní kritiku.

Emailová adresa:

min: 6 ([email protected]). Nebo 3, pokud chcete sledovat e-mailové adresy v místní doméně
max: 320 254 (RFC)

Množství kódu pro ověření e-mailu je ve skutečnosti šílené, takže předpokládejme, že je platný, pokud má znak „@“

Možná budete chtít abstraktní e-mailovou adresu označit jako „způsob komunikace“, abyste mohli snadno vyjmenovat všechny způsoby komunikace s uživatelem.

Rod

Pohlaví se může časem měnit, takže můžete sledovat, zda je to pro vás důležité. Postupujte http://en.wikipedia.org/wiki/ISO/IEC_5218

NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);

Adresy: NORAM

Půjdu levným směrem ven a držím se severoamerických adres.

Je vhodné abstraktní země, divize, města a okresy hlavně kvůli zdanění. Daně se mohou uplatňovat na mnoha úrovních, takže pokud můžete zaměřit daňovou sazbu na abstraktní geografickou oblast, jste zlatí.

GeographicArea :

id: int  
type: {country, division, county, city, indian reservation}  
name: varchar(45)  [1]
abbreviation: nullable varchar(4)  
parent_id: nullable int  

Adresa :

id: int  
postal_area_id: int, references GeographicArea  
county_or_city_id: int, references GeographicArea  
street_address: varchar(255)  
suite: nullable varchar(255)  

Pokud potřebujete, přidejte řádky 2 a 3.

Viz http://en.wikipedia.org/wiki/Address_ (geografie)

Nyní je adresa adresa. Na jedné adrese může žít více lidí a člověk může mít více adres najednou a v průběhu času, takže k tomu potřebujete tabulku s mnoha čísly.

PartyAddress

party_id: int references Party  
address_id: int references Address  
purpose: {home, work, ...}  

Přidat from_date a nulovatelné to_date pokud sledování v čase.

Telefonní čísla

Strana může mít více telefonních čísel a telefonní číslo může používat více lidí. Telefonní číslo lze použít pro faxy, telefonní hovory, modemy atd. A může mít rozšíření. To vše se může časem změnit.

Telefonní číslo

id: int  
value: varchar(15) - the max allowed by the ITU  

Minimální hodnota může být 3 (pro „911“) nebo možná 7 („310-4NET“, což je zvláštní druh místního čísla, které vám neumožňuje vytočit směrové číslo oblasti)

Dalo by se to v případě potřeby rozdělit na kód země atd.

Měli byste použít standard http://en.wikipedia.org/wiki/E.164

PartyPhoneNumber

party_id: int references Party  
phone_number_id references PhoneNumber  
extension: nullable varchar(11) - ITU max  
purpose: {home, work, fax, modem, ...}  

Jména

Jména jsou tvrdá. Zde je proč:

  1. Někteří lidé mají legální jméno, v němž je pouze jedno slovo http://en.wikipedia.org/wiki/List_of_legally_mononymous_people

  2. Někteří lidé mají jména s mnoha slovy http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior

  3. Někteří lidé mají více jmen najednou (například na mé univerzitě je mnoho asijských studentů, ale rádi používají "preferovaná" více westernizovaná jména)

  4. Někdy je třeba sledovat jména lidí v průběhu času, například rodná jména a manželská jména.

  5. Chcete abstraktní jednotlivce a organizace z různých dobrých důvodů

    vytvořit stolní párty (id bigserial primární klíč);

    vytvořit tabulku party_name (id bigserial primární klíč, party_id bigint není null reference party (id), napište smallint not null reference party_name_type (id) - podporované, ex "baby", "legal");

    vytvořit tabulku name_component (id bigserial primární klíč, party_name_id bigint není null reference party_name (id), zadejte smallint not null reference name_component_type (id), --elided ex "daný" text názvu null null);

9
Neil McGuigan

Z poněkud odlišné perspektivy než předchozí odpovědi, a protože zdá se, že mluví o LDAP , RFC 4519 - "Lightweight Directory Access Protocol (LDAP): Schéma pro uživatelské aplikace" může být zajímavý.

Může být užitečné, pokud je třeba vaši aplikaci namapovat do takového adresáře. Jinak to pravděpodobně nebude přizpůsobeno vašim požadavkům.

Tyto definice se netýkají pouze dat, ale také některých operátorů, které lze v polích použít. postalAddress , například je caseIgnoreListSubstringsMatch . Nenavrhuji, abyste měli toto schéma přísně dodržovat, ale při pohledu na principy by mohlo být zajímavé, zejména to, jak budete možná muset porovnat jméno a adresy ve vaší aplikaci, může být relevantní pro návrh vaší databáze.

3
Bruno

Pokud jde o jména, zvažte použití uvozovek, takže nemusíte unikat apostrofům v irských nebo italských jménech (např. O'Hara nebo D'Amato).

Doporučuji také použití dobré sady regulárních výrazů, abyste mohli použít části svých polí (např. První iniciála, přezdívka, Jr/Sr atd.).

3
KiloVoltaire