Práticas recomendadas em campos de pessoas comuns (nome, email, endereço, sexo, etc.) [fechado]

Quais são as práticas recomendadas mais comuns em tamanho e tipo de dados em campos comuns, como:

• Primeiro nome
• Último nome
• Endereço
• O email
• Sexo
• Estado
• Cidade
• País
• Número de telefone

etc ....

Eu tenderia a desconfiar de qualquer conjunto de melhores práticas universais porque, para a maioria desses campos, o diabo está nos detalhes. Só porque as informações são relativamente comuns, não significa que seu aplicativo use os dados exatamente da mesma maneira que outros aplicativos. Isso significa que seu modelo de dados pode precisar ser um pouco diferente.

• Nome e sobrenome: Por que você está capturando o nome? Se você precisa capturar o nome legal completo de uma pessoa (por exemplo, está preparando documentos legais ou certidões de nascimento), provavelmente deseja permitir mais espaço para as pessoas digitarem do que você faria se estivesse apenas pedindo o nome de uma pessoa para tem algo para chamá-los em seu novo aplicativo da web.
• Endereço: O que você vai fazer com o endereço? Que tipo de endereços você está armazenando? Se você estiver armazenando o endereço de uma propriedade nos Estados Unidos em que está criando uma hipoteca, provavelmente se preocupará muito em obter um endereço totalmente padronizado. Nesse caso, o modelo de dados provavelmente desejará se aproximar muito do seu endereço ferramenta de padronização retorna. Se você apenas deseja que as pessoas possam digitar um endereço para entregar um produto, provavelmente algumas linhas para texto em formato livre provavelmente serão suficientes. O comprimento das linhas pode depender dos requisitos dos processos posteriores que fazem coisas como imprimir etiquetas de endereço.
• Estado: Supondo que você possa identificar os valores de estado válidos, provavelmente faz sentido criar uma STATEtabela e criar um relacionamento de chave estrangeira entre as tabelas STATEe ADDRESS. Mas a capacidade de identificar os valores válidos implica que você está limitando o conjunto de endereços válidos pelo menos a um conjunto específico de países. Isso é bom para muitos sites, mas você precisa trabalhar um pouco para dar suporte a um novo país.
• Cidade: se você estiver lidando com dados em que existem regulamentos em potencial no nível da cidade (por exemplo, onde existem diferentes tipos de taxas de imposto aplicadas com base na cidade), convém tratá-lo da mesma forma que o estado e ter um CITYmesa com as cidades válidos e uma relação de chave estrangeira entre a CITYe ADDRESSmesas. Por outro lado, se você está apenas tentando obter um produto entregue e não se importa muito em ter várias versões da mesma cidade em sua tabela, é suficiente deixar o usuário digitar o texto de forma livre. Obviamente, se você estiver armazenando chaves estrangeiras, terá bastante trabalho para se certificar de que possui todos os valores válidos. Mas há produtos em que o ponto principal é que a empresa já fez esse trabalho (ou seja, bancos de dados de impostos sobre vendas).
• Telefone: O que você está fazendo com números de telefone e por quê? Alguns aplicativos desejam receber números de telefone em qualquer formato que o usuário decidir inseri-los e preservar essa formatação para todas as consultas subseqüentes. Isso seria comum se você estiver criando um catálogo de endereços pessoal, no qual os usuários tenham suas próprias preferências de como os números de telefone são armazenados e exibidos. Outros aplicativos desejam ignorar a formatação inserida, extrair apenas os caracteres numéricos e formatar os dados na recuperação, para que todos os números de telefone tenham uma formatação semelhante. Se você estiver atendendo a empresas, convém um campo separado para os usuários inserirem uma extensão. Se você estiver tentando oferecer suporte a um processo de chamada de saída, convém armazenar o código de área e o código do país em colunas separadas, porque você '
• Gênero: Para muitas aplicações, é perfeitamente razoável armazenar um código de gênero ('M' ou 'F') em uma tabela. Por outro lado, há casos em que você pode querer opções adicionais (Outro, Intersexo, Transgêneros) ou onde você precisa armazenar algo como o sexo no nascimento e o atual.

Você também pode adivinhar com base em dados de amostra e público-alvo esperado. Isso depende de sua localização.

Algumas notas:

Endereços:

• Eu não tenho um estado e isso me irrita quando tenho que escolher "Fora dos EUA"
• Os condados postais do Reino Unido não têm semelhança com as principais regiões do governo local: consulte "Tipo e tamanho da coluna para subdivisões de países internacionais (estados, províncias, territórios etc.)" no SO, onde eu quebrei as suposições de alguém

Nomes:

• Não esqueça o nome de família, nome próprio, conhecido como, nome tribal, patronímico, nome de geração etc.
• Veja "Programadores de falsidades acreditam em nomes" e considere chorar
• Veja "Sobrenome Primeiro" e apenas chore
• SO "Qual é o nome humano mais longo que você pode esperar?" para um exemplo trabalhado

Número de telefone: código internacional, comprimento, celular x casa, permite celular como número único

Além das ótimas respostas acima, não esqueça de aceitar caracteres unicode. Só porque você está nos EUA não significa que não deseja aceitar caracteres estrangeiros em suas colunas.

Dito isto, eu geralmente recomendo 50 caracteres para nomes. 320 deve ser mais que suficiente para um endereço de email (você pode verificar o padrão ANSI para ter certeza). Para erro de endereço no lado do cuidado com 255 caracteres. Embora você provavelmente nunca precise de um endereço tão grande, talvez precise incluir linhas de C / O e coisas assim. A cidade deve ser bem grande, existem nomes de cidades bastante longos por aí. Para o estado, vá com uma tabela filho, o mesmo com o país. Para o código postal, não se esqueça dos códigos postais internacionais que são mais longos que os códigos postais dos EUA. Só porque você não apoia internacional, você ainda pode ser. Existem muitos cidadãos dos EUA que vivem em diferentes países, incluindo militares.

Não esqueça que o estado deve ser opcional, pois muitos países não têm estados.

Meu bumbum está ficando dolorido por estar sentado em cima do muro, então vou dar algumas respostas e espero não ser votado no esquecimento. Por favor, ofereça críticas construtivas.

Endereço de e-mail:

min: 6 ([email protected]). Ou 3, se você deseja rastrear os endereços de email do domínio local no
máximo: 320 254 (RFC)

A quantidade de código para validar um email é realmente insana, então vamos supor que seja válido se tiver um "@"

Você pode abstrair um endereço de email como um "método de comunicação", para poder listar facilmente todos os métodos com os quais se comunicar com um usuário.

Gênero

O gênero pode mudar com o tempo, para que você possa acompanhar isso se for importante para você. Siga http://en.wikipedia.org/wiki/ISO/IEC_5218

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

Endereços: NORAM

Vou pegar o caminho mais barato e seguir os endereços da América do Norte.

É conveniente abstrair países, divisões, cidades e municípios principalmente devido à tributação. Os impostos podem ser aplicados em vários níveis; portanto, se você pode apontar uma taxa de imposto para uma área geográfica abstrata, você é ouro.

Área geográfica :

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

Endereço :

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

Adicione line2 e line3, se necessário.

Veja http://en.wikipedia.org/wiki/Address_(geography)

Agora, um endereço é um endereço. Várias pessoas podem morar em um endereço, e uma pessoa pode ter vários endereços ao mesmo tempo e ao longo do tempo, portanto, você precisa de uma tabela muitas para isso.

PartyAddress

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

Adicione from_datee anulável to_datese estiver acompanhando ao longo do tempo.

Números de telefone

Uma parte pode ter vários números de telefone e um número de telefone pode ser usado por várias pessoas. Um número de telefone pode ser usado para faxes, chamadas telefônicas, modems etc. e pode ter ramais. Tudo isso pode mudar com o tempo também.

Número de telefone

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

O mínimo pode ser 3 (para "911") ou talvez 7 ("310-4NET", que é um tipo especial de número local que não permite que você disque o código de área)

Você pode dividir isso em código de país, etc., se necessário.

Você deve usar o http://en.wikipedia.org/wiki/E.164 padrão

PartyPhoneNumber

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

Nomes

Os nomes são difíceis. Aqui está o porquê:

1. Algumas pessoas têm um nome legal com apenas uma palavra http://en.wikipedia.org/wiki/List_of_legally_mononymous_people

2. Algumas pessoas têm nomes com muitas palavras http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior

3. Algumas pessoas têm vários nomes ao mesmo tempo (por exemplo, na minha universidade, há muitos estudantes asiáticos, mas eles gostam de usar nomes mais preferidos e ocidentais)

4. Às vezes, é necessário rastrear os nomes das pessoas ao longo do tempo, como nomes de solteira e nomes de casados.

5. Você deseja abstrair indivíduos e organizações por várias boas razões

   criar grupo de tabelas (chave primária bigserial de identificação);

   crie a tabela party_name (id bigserial key primária, party_id bigint não nulo faz referência a party (id), digite smallint não null null party_name_type (id) --elected, ex "maiden", "legal");

   crie a tabela name_component (id bigserial key primária, party_name_id bigint não nulo faz referência a party_name (id), digite smallint not null faz referência a name_component_type (id), --selected ex "dado" nome texto não nulo);

De uma perspectiva ligeiramente diferente das respostas anteriores, e como parece correto falar sobre LDAP , a RFC 4519 - "LDAP (Lightweight Directory Access Protocol): esquema para aplicativos do usuário" pode ser interessante.

Pode ser útil se seu aplicativo precisar ser mapeado para esse diretório. Caso contrário, provavelmente não está adaptado aos seus requisitos.

Essas definições são mais do que apenas dados, mas também alguns operadores que podem ser usados ​​nos campos. postalAddress, por exemplo, é a caseIgnoreListSubstringsMatch. Não estou sugerindo que você adira estritamente a esse esquema, mas observar os princípios pode ser interessante, especialmente como você pode ter que comparar o nome e os endereços em seu aplicativo pode ser relevante para o design do seu banco de dados.

Em relação aos nomes, considere usar aspas duplas para não precisar apóstrofos em nomes irlandeses ou italianos (por exemplo, O'Hara ou D'Amato).

Também recomendo a utilização de um bom conjunto de expressões regulares, para que você possa produzir partes de seus campos de nome (por exemplo, primeira inicial, apelido, Jr / Sr, etc.).