Início / dba / Perguntas / 301153
Accepted
Dirk Boer
Asked: 2021-10-15 14:43:10 +0800 CST

Escolha entre dois antipadrões: Overdesign versus Over-optimization

  • 772

Às vezes eu preciso manter o estado, como um sinalizador IsVerified.

Existem duas opções:

booleano (ou bit)

Vantagem: menor e mais rápido

...mas em teoria "super-otimização" e, portanto, um argumento ruim.

data e hora anuláveis

IsVerifiedOn -> NULL não é verificado, qualquer valor significa verificado.

Vantagem: você pode ter uma situação no futuro em que de repente se deparar com um caso em que é útil que você realmente saiba quando essa conta foi verificada.

...mas em teoria "sobre design" (You Are't Gonna Need It) e você só deve adicionar isso quando realmente precisar.

Então, entre esses dois males? Qual é o melhor para começar?

database-design performance

2 respostas

  1. Você pode precisar de NULL na data IsVerifiedOn para outra finalidade posteriormente. Se surgir uma situação em que você sabe que algo foi verificado, mas não sabe a data em que foi verificado, você terá problemas, porque não pode dizer isso. Em geral, NULL em um campo sempre significa "sem dados aqui". Atribuir-lhe outro significado sempre pode criar problemas potenciais no futuro.

    • 2
  2. Best Answer

    Eu acredito que você pode estar "pensando demais". Eu nunca ouvi a frase " otimização excessiva é um antipadrão " e geralmente discordo disso.

    Em vez de se preocupar muito com antipadrões, arquitete seus casos de uso e seja razoável . Se você sabe que nunca precisará razoavelmente do IsVerifiedOncampo datetime em um futuro próximo, provavelmente não há problema em usar o IsVerifiedcampo bit. Se houver um uso potencial razoável em ter o IsVerifiedOncampo, então utilize esse campo. Não há resposta certa ou errada aqui, e depende novamente do que é razoável para seus casos de uso.

    Aqui está outro anti-padrão, pode-se até considerar, que explode os dois que você mencionou: é chamado de "um campo múltiplos propósitos". Significa o que diz, ou seja, tecnicamente é consideravelmente um antipadrão ter um campo com vários propósitos, como IsVerifiedOnsugere a descrição da coluna. O primeiro objetivo é identificar se uma linha é verificada e o segundo objetivo é identificar quando foi verificada.

    Uma razão pela qual isso é considerado um antipadrão é porque um dia esse campo pode ter um valor que atenda bem a um propósito enquanto quebra a lógica ou não faz sentido para o outro propósito. Por exemplo, no seu caso, você pode ter outra tabela derivada do seu IsVerifiedOncampo. Essa segunda tabela contém apenas registros das últimas 10 linhas verificadas em sua primeira tabela. Agora alguém decide cancelar a verificação de sua primeira tabela anulando o IsVerifiedOncampo para os últimos registros, mas esquecem de limpar os últimos registros da segunda tabela. Agora você perde a integridade dos dados.

    A melhor prática contra esse antipadrão, na verdade, aconselha a implementação de um IsVerifiedcampo e um VerifiedOncampo para manter separadamente esses dois propósitos. Mas, novamente, isso também depende de seus casos de uso realistas dentro da razão e também nem sempre precisa ser respeitado. Se você sempre tenta projetar seu esquema razoavelmente, não precisa pensar muito em antipadrões.

    (Ps, na verdade, dei um exemplo bem fraco no antipadrão "um campo, vários propósitos", mas há muitas coisas realistas que quebram a integridade de dados que podem acontecer como resultado disso. Então, apesar do meu exemplo ruim, espero que ainda comunica a ideia.)

    • 1

relate perguntas