Quais são as práticas recomendadas mais comuns em tamanho e tipo de dados em campos comuns, como:
etc ....
Respostas:
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.
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.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).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:
Nomes:
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.
min: 6 (a@g.cn). 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.
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);
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.
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, ...}
Os nomes são difíceis. Aqui está o porquê:
Algumas pessoas têm um nome legal com apenas uma palavra http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
Algumas pessoas têm nomes com muitas palavras http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
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)
Às vezes, é necessário rastrear os nomes das pessoas ao longo do tempo, como nomes de solteira e nomes de casados.
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.).