Início / dba / Perguntas / 242995
Accepted
James
Asked: 2019-07-17 06:04:43 +0800 CST

Quais são as práticas recomendadas para alterar o e-mail de um usuário em um aplicativo?

  • 772

Estou trabalhando em um rud para um aplicativo de e-mail e gostaria de poder mudar "tudo". No momento, no entanto, ele corresponde à string JSON ao banco de dados com base no endereço de e-mail.

Problema: Nesse modelo, um usuário nunca pode alterar seu e-mail. Um novo endereço de e-mail = um novo usuário.

    declare @email varchar(255),
    @ID int

    insert into announcement_jsonlog (json_string)
    values (@json)

    select @email = email from 
            openjson(@json)
            WITH
            (email varchar(255)         '$.Email')


    insert into announcement_contacthistory (   
    ID, Email, Prefix, FirstName, MiddleInitial, LastName, Suffix, Title, Company, Address1, Address2, City, State, Zip, Zip_4, Phone, Extension, Unregistered, AddDateTime, LModifiedDateTime, 
    longkey, shortkey, History_addDateTime)

    select *, current_timestamp from announcement_contact
    where email = @email

Pergunta: como você criaria um CRUD que permitisse alterar o endereço de e-mail também?

azure-sql-database json

1 respostas

  1. Best Answer

    Parece que você está usando o endereço de e-mail como chave, o que não é uma boa prática. Qualquer coisa que possa mudar não é um bom candidato para ser um valor-chave que inclui endereços de e-mail e números de telefone. Outras razões pelas quais não é uma boa ideia incluem:

    • Pode ser NULL: talvez haja pessoas em seu público-alvo que não usam e-mail, então não terão um endereço?
    • Alguém pode ter mais de um endereço/número
    • As pessoas podem compartilhar um endereço/número para que não seja único

    Se você não tiver um valor inalterável, único e nunca NULL que seja, portanto, um candidato a ser o valor da chave, é comum ter uma chave substituta gerada: mais comumente um valor inteiro ou UUID que é decidido quando o registro é criado e não depende de nenhuma propriedade do registro. Você parece ter essa chave já em sua announcement_contacthistorytabela, a IDcoluna.

    Isso é particularmente importante se o valor da chave for referenciado por valores de chave estrangeira em outras tabelas, como parece ser o caso aqui. Embora o SQL Server e o Azure SQL DB tenham o ON UPDATE CASCADEque torna possível e fácil alterar esses valores referidos do ponto de vista dos codificadores (basta atualizar o valor primário, o mecanismo desaparecerá e corrigirá todas as referências), isso pode ser muito ineficiente, resultando em um muitas mudanças relacionadas sendo feitas. Se announcement_contacthistorytivesse uma referência ao announcement_contact.idinvés de announcement_contact.emailvocê poderia alterar o email de um usuário sem precisar atualizar todas as referências em announcement_contacthistorye em outros lugares.

    Claro que você pode querer manter um histórico de endereços de e-mail para saber o que foi usado no momento em que as mensagens foram enviadas, seja gravando o endereço no registro da mensagem ou mantendo um histórico dos valores na tabela de contatos (talvez usando uma tabela temporal com versão do sistema).

    Para encontrar informações sobre a teoria e a prática relevantes, pesquise os seguintes termos:

    • Chave
    • Chave candidata
    • Chave substituta
    • Chave primária
    • Chave única
    • 3

relate perguntas