Livro de endereços do esquema de banco de dados

StackOverflow https://stackoverflow.com/questions/38352

Pergunta

Eu preciso armazenar informações de contato para os usuários.Eu quero apresentar esses dados na página como um hCard e disponível para download como um vCard.Eu também gostaria de ser capaz de pesquisar o banco de dados através do número de telefone, e-mail, etc.

O que você acha que é a melhor maneira de armazenar esses dados?Uma vez que os usuários podem ter vários endereços, etc completa normalização seria uma bagunça.Eu estou pensando em usar XML, mas eu não estou familiarizado com a consultar XML db campos.Eu iria ainda ser capaz de pesquisar usuários por informações de contacto?

Eu estou usando o SQL Server 2005, se o que importa.

Foi útil?

Solução

Considere duas tabelas para as Pessoas e seus endereços: 

People (pid, prefix, firstName, lastName, suffix, DOB, ... primaryAddressTag )

AddressBook (pid, tag, address1, address2, city, stateProv, postalCode, ... )

A Chave Primária (que identifica exclusivamente cada linha) de Pessoas é pid.O PK de Livro de endereços é a composição do pid e tag (pid, tag).

Alguns dados de exemplo:

Pessoas

1, Kirk

2, Spock

Livro de endereços

1, home, '123 Main Street', Iowa

1, work, 'USS Enterprise NCC-1701'

2, other, 'Mt. Selaya, Vulcan'

Neste exemplo, Kirk tem dois endereços:um 'lar' e um 'trabalho'.Um dos dois pode (e deve) ser observado como uma chave externa (como uma referência cruzada) em People no primaryAddressTag coluna.

Spock tem um único endereço com a tag 'outros'.Desde que Spock só endereço, o valor de "outras" deveria ir no primaryAddressTag coluna pid=2.

Este esquema tem o bom efeito de impedir que a mesma pessoa com a duplicação de qualquer de seus próprios endereços acidentalmente por reutilização de tags ao mesmo tempo, permitindo que todas as outras pessoas de utilizar qualquer endereço de marcas que eles gostam.

Além disso, com o FK referências primaryAddressTag, o banco de dados do próprio sistema irá impor a validade do endereço principal marca (através de algo que nós do banco de dados geeks chamada de integridade referencial), de modo a que o seu-ou qualquer -- aplicação não precisa se preocupar com isso.

Outras dicas

Por que completa normalização "ser uma bagunça"?Este é exatamente o tipo de coisa que a normalização torna menos confuso.

Não tenha medo de normalizar os seus dados.Normalização, como João menciona, é a solução, não o problema.Se você tentar desnormalizar os seus dados apenas para evitar um casal se junta, então você vai causar a si mesmo sérios problemas no futuro.Tentando refatorar este tipo de dados para baixo da linha depois de ter um tamanho razoável conjunto de dados NÃO VAI SER DIVERTIDO.

Eu sugiro que você confira Highrise a partir de 36 Sinais.Recentemente, foi-me recomendado quando eu estava procurando por um contato on-line manager.Ele faz isso muito certo.Na verdade, a minha única objeção tão longe com o serviço é que eu acho que as versões pagas são muito caros-isso é tudo.

Como as coisas estão hoje, eu não me encaixo em um endereço simples de perfil.Eu tenho 4-5 e-mail que eu uso regularmente, 5 números de telefone, de 3 endereços, vários sites e IM perfis, tudo o que eu gostaria de incluir no meu perfil.Se você está começando a construir um sistema de gestão de contactos e agora você está livre de limitações arquitetônicas (acho que o gmail cantacts sendo introduzidos para um único endereço de e-mail) e, em seguida, fazer o seu blog um favor e faça seu contato estrutura flexível (normalizado) possível.

Felicidades, -D.

Eu estou ciente de SQLite, mas isso realmente não ajuda - estou falando de descobrir a melhor esquema (independentemente do banco de dados) para armazenamento de dados.

Por John, eu não vejo qual é o problema com um clássico normalizada esquema seria.Você não deu muita informação, mas você diz que há uma relação um-para-muitos de relacionamento entre os usuários e seus endereços, assim que eu gordo para um pântano de solução padrão com uma chave estrangeira para o usuário na relação de endereços.

Se você supor que cada usuário tem um ou mais endereços, um número de telefone, etc., você poderia ter um 'Blog' tabela, um dos Endereços da Tabela' (que contém uma chave primária e, em seguida, não-exclusivo de referência para os Usuários), o mesmo para números de telefone, permitindo várias linhas com o mesmo id de utilizador, chave estrangeira, o que tornaria a consulta 'todos os endereços do usuário X' bastante simples.

Eu não tiver um script, mas eu tenho o mySQL que você pode usar.Antes que eu mencionei que parece que existem duas abordagens lógicas para armazenar cartões de visita em SQL:

  1. Armazenamento de toda a placa e permitem que o banco de dados da pesquisa, (possivelmente) enorme seqüências de caracteres de texto, e processá-los em outra parte do seu código ou até mesmo do lado do cliente.exemplo:

    CREATE TABLE IF NOT EXISTS vcards (
    name_or_letter varchar(250) not NULL,
    vcard o texto NÃO NULO,
    timestamp carimbo de data / hora padrão CURRENT_TIMESTAMP na atualização CURRENT_TIMESTAMP,
    CHAVE PRIMÁRIA (username)
    ) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

Provavelmente, fácil de implementar, (dependendo do que você está fazendo com os dados) através de suas pesquisas vai ser lento se você tiver muitas entradas.Se esta é só para você, em seguida, isso pode funcionar, (se ele é bom, então é nunca só para você.) Em seguida, você pode processar o vCard do lado do cliente ou do lado do servidor usando algumas belas módulo que você compartilha, (ou outra pessoa compartilhados com você.)

Eu já assisti vCard evoluir e sei que não vai ser algumas mudanças no /alguns/ hora, no futuro, por isso uso três tabelas.

O primeiro é o do cartão, (principalmente em links de volta para o meu tabelas existentes - se você não precisa isso, então, o seu pode ser um corte de versão).O segundo são as definições do cartão, (que parecem ser chamado de perfil no vCard falar).A última é que todos os dados reais para as cartas.

Porque eu deixei DBIx::Class, (sim, eu sou um desses) fazer todo o trabalho de banco de dados este (três tabelas) parece funcionar muito bem para mim, (embora, obviamente, você pode apertar os tipos de correspondência rfc2426 mais de perto, mas a maior parte de cada pedaço de dados é apenas uma seqüência de caracteres de texto.)

A razão que eu não normalizar o endereço da pessoa é que eu já tenho uma tabela de endereços em meu banco de dados e estes três são só para o usuário não-detalhes de contacto.

 CREATE TABLE `vCards` (   
 `card_id` int(255) unsigned NOT NULL AUTO_INCREMENT,   
 `card_peid` int(255) DEFAULT NULL COMMENT 'link back to user table',   
 `card_acid` int(255) DEFAULT NULL COMMENT 'link back to account table',      
 `card_language` varchar(5) DEFAULT NULL COMMENT 'en en_GB',
 `card_encoding` varchar(32) DEFAULT 'UTF-8' COMMENT 'why use anything else?',
 `card_created` datetime NOT NULL,  
 `card_updated` datetime NOT NULL,
 PRIMARY KEY (`card_id`) )
 ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='These are the contact cards'

   create table vCard_profile (
    vcprofile_id int(255) unsigned auto_increment NOT NULL,
    vcprofile_version enum('rfc2426') DEFAULT "rfc2426" COMMENT "defaults to vCard 3.0",
    vcprofile_feature char(16) COMMENT "FN to CATEGORIES",
    vcprofile_type enum('text','bin') DEFAULT "text" COMMENT "if it is too large for vcd_value then user vcd_bin",
  PRIMARY KEY (`vcprofile_id`)
) COMMENT "These are the valid types of card entry";
INSERT INTO vCard_profile VALUES('','rfc2426','FN','text'),('','rfc2426','N','text'),('','rfc2426','NICKNAME','text'),('','rfc2426','PHOTO','bin'),('','rfc2426','BDAY','text'),('','rfc2426','ADR','text'),('','rfc2426','LABEL','text'),('','rfc2426','TEL','text'),('','rfc2426','EMAIL','text'),('','rfc2426','MAILER','text'),('','rfc2426','TZ','text'),('','rfc2426','GEO','text'),('','rfc2426','TITLE','text'),('','rfc2426','ROLE','text'),('','rfc2426','LOGO','bin'),('','rfc2426','AGENT','text'),('','rfc2426','ORG','text'),('','rfc2426','CATEGORIES','text'),('','rfc2426','NOTE','text'),('','rfc2426','PRODID','text'),('','rfc2426','REV','text'),('','rfc2426','SORT-STRING','text'),('','rfc2426','SOUND','bin'),('','rfc2426','UID','text'),('','rfc2426','URL','text'),('','rfc2426','VERSION','text'),('','rfc2426','CLASS','text'),('','rfc2426','KEY','bin');

create table vCard_data (
    vcd_id int(255) unsigned auto_increment NOT NULL,
    vcd_card_id int(255) NOT NULL,
    vcd_profile_id int(255) NOT NULL,
    vcd_prof_detail varchar(255) COMMENT "work,home,preferred,order for e.g. multiple email addresses",
    vcd_value varchar(255),
    vcd_bin blob COMMENT "for when varchar(255) is too small",
    PRIMARY KEY (`vcd_id`)
) COMMENT "The actual vCard data";

Esta não é a melhor SQL, mas espero que ajude.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top