Início / dba / Perguntas / 19039
Accepted
xenoterracide
Asked: 2012-06-11 10:57:13 +0800 CST

id e número de telefone são suficientes para identificar exclusivamente uma linha em números de telefone

  • 772

Estava projetando uma tabela uma customer_phone_numberstabela um tempo atrás, cujo único propósito era nos permitir armazenar quantos números de telefone um usuário quisesse ter em arquivo. Originalmente, cheguei à conclusão de que customer_id+ phone_numberera único, mas então me ocorreu que é possível que o mesmo usuário tenha 2 ramais no mesmo número. Não tenho certeza da probabilidade disso, e isso cria outro problema.

phone_number ext
555-555-555, NULL
555-555-555, NULL

torna-se legal, a menos que eu encontre uma boa maneira de restringir ext contra null. Qual é a melhor maneira de normalizar e restringir números de telefone?

database-design normalization

3 respostas

  1. Best Answer

    Provavelmente existem maneiras de resolver isso (por exemplo, um gatilho em vez de uma restrição explícita ou um índice filtrado inteligente se em 2008+), mas por quê?

    Por exemplo, você pode fazer isso com dois índices filtrados em 2008+:

    CREATE TABLE #cpn(c INT, pn VARCHAR(32), x VARCHAR(8000));

CREATE UNIQUE INDEX x ON #cpn(c, pn) WHERE x IS NULL;
CREATE UNIQUE INDEX y ON #cpn(c, pn, x) WHERE x IS NOT NULL;

INSERT #cpn(c, pn   ) SELECT 1, '555-5555';        -- OK
INSERT #cpn(c, pn, x) SELECT 1, '555-5555', '345'; -- OK
INSERT #cpn(c, pn, x) SELECT 1, '555-5555', '555'; -- OK
GO
INSERT #cpn(c, pn   ) SELECT 1, '555-5555';        -- fails on index x
GO
INSERT #cpn(c, pn, x) SELECT 1, '555-5555', '345'; -- fails on index y

    Mas eu não consigo ver o ponto. Isso parece uma flexibilidade desnecessária. Se vou ligar para o escritório e tentar falar com Bob no ramal 55, por que seria mais provável que eu o encontrasse no ramal 67? Isso parece um cenário viável do mundo real para alguém?

    Sugiro que você torne uma regra de negócios que um usuário possa ter apenas um ramal no mesmo número. Dessa forma, você pode manter sua restrição no ID do cliente e no número de telefone e permitir que a extensão seja opcional.

    Além disso, supondo que você esteja armazenando números de telefone e extensões como strings, você pode seguir o caminho inverso e permitir que as pessoas os insiram juntos em vez de separados. Se eles querem inserir 15 ramais diferentes no mesmo número, por que impedi-los? Também acho bobo permitir uma extensão de 0, mas isso também permitiria.

    • 3

  2. Apenas jogando por aí: você poderia colocar seu PK em { CustomerID, PhoneType }. Você estaria armazenando um pouco de contexto sobre o significado de cada número de telefone, o que pode ser útil.

    Se você tornar PhoneType uma string de texto livre em vez de um FK para uma tabela de dimensão PhoneTypes, permitirá um número indefinido de números de telefone por cliente (ou poderá torná-lo um FK, mas permitir que os usuários criem novos tipos de telefone, embora eu não não vá longe). No entanto, incentive os usuários a escolher em uma lista de tipos de telefone comuns (trabalho, casa, celular, fax).

    • 2

  3. Você não pode criar uma restrição UNIQUE e permitir NULL em sql server , então acho que você pode armazenar o valor padrão 0 no ext e, ao exibi-lo, use case para exibir ext como valor vazio

    Select 
customer_id, 
phone_number, 
ext = case when ext = 0 then '' else ext  
end
    • 0

relate perguntas