Início / dba / Perguntas / 321543
Accepted
soger
Asked: 2022-12-30 09:56:03 +0800 CST

O conteúdo misto em uma coluna é um design ruim?

  • 772

Tenho um colega que vive colocando conteúdo misto em uma coluna. Por exemplo, este caso atual com o qual estou lutando é uma coluna chamada "opts", que é uma matriz de inteiros. Dependendo de um tipo que nem está presente na linha atual, você terá que juntar outra tabela para descobrir isso, esta coluna pode conter:

  • um 0 ou um 1 - significando um estado ligado/desligado
  • uma lista de IDs de uma tabela
  • uma lista de IDs de uma segunda tabela
  • null em qualquer outro caso

Para mim, isso parece mais desordem do que dados organizados. Então, existe um conceito de design de banco de dados que isso viola ou é apenas meu TOC? Quais devem ser meus argumentos quando tento persuadi-lo a não fazer mais isso?

Gostaria de acrescentar que os IDs da tabela não precisam de chaves estrangeiras por motivos que não vale a pena entrar, o colega faz isso com outras coisas também, por exemplo outra coluna em outra tabela tem uma string ou um texto json . O que eu faria nesses casos é ter mais colunas, uma para cada caso, e preencher apenas uma delas e deixar as demais como nulas.

database-design

1 respostas

  1. Best Answer

    Primeiro estou fazendo algumas suposições:

    • "Uma lista de IDs" significa uma string separada por vírgula, como 1,2,3,4,5etc
    • Sua coluna optsé um tipo de dados de string como VARCHAR / NVARCHAR / CHAR etc

    Você não menciona seu DBMS. Minha resposta é baseada no SQL Server, então algumas das coisas que mencionei podem não ser relevantes para outros DBMS

    Para mim, o padrão que você descreve é ​​"One True lookup table (OTLT)", onde você tem uma única tabela de várias entidades diferenciadas por alguma chave ou valor, por exemplo:

    +----+------------+-------+---------------------+
| ID |  category  | Name  |     DateCreated     |
+----+------------+-------+---------------------+
|  1 | Person     | John  | 2022-12-29T00:00:00 |
|  2 | Person     | Jim   | 2022-12-29T01:00:00 |
|  3 | Department | I.T   | 2022-12-29T02:00:00 |
+----+------------+-------+---------------------+

    Isso pode ser usado porque quando um novo tipo de entidade é criado, ele pode ser criado inserindo dados em uma tabela em vez de alterar o esquema do banco de dados. Pode potencialmente ser válido quando os diferentes tipos de entidades têm propriedades comuns (no caso acima - um nome e uma data de criação)

    No entanto, começa a cair quando queremos adicionar novas propriedades a uma entidade, por exemplo, a idade de uma pessoa. Nesse caso, adicionaríamos uma coluna de idade à tabela, mas o valor nessa coluna teria significado apenas para algumas das linhas da tabela; isso pode rapidamente se tornar confuso e difícil de trabalhar.

    Algumas reflexões sobre por que o OTLT e o armazenamento de listas delimitadas por vírgulas são ruins

    Para facilitar a explicação, direi que você tem uma linha que possui uma lista de PersonIDs que são armazenados nesta tabela por algum motivo e que você tem uma tabela de pessoa separada onde PersonID é exclusivo

    • Falta de restrição - se um determinado tipo de entidade requer um 1 ou um 0, mas a coluna é VARCHAR, não há nada para impedir que algum outro valor ilegal seja inserido, como 'abc' (talvez uma restrição CHECK, mas é provável que se torne complicada, propenso a erros e precisa ser atualizado toda vez que uma nova categoria é criada)
    • Se precisarmos nos juntar à tabela de pessoas para obter qualquer informação sobre uma ou mais pessoas na lista de ID, teremos que fazer uma divisão de string que pode ser ruim para o desempenho, pois também depende da lista delimitada por vírgulas sendo inserido em um formato padrão
    • Não podemos ver facilmente todas as pessoas na tabela de pessoas que não estão listadas nesta tabela (novamente, conseguiríamos isso por meio de uma antijunção à esquerda)
    • A indexação será quase impossível
    • É mais provável que a tabela cause um problema de bloqueio em seu banco de dados, pois mais consultas a usarão, a maioria será ineficiente e lenta pelos motivos mencionados acima, o que significa que os bloqueios serão mais longos e as consultas em espera esperarão mais
    • Você mencionou que os dados não precisam ser uma chave estrangeira, mas se isso acontecer no futuro, você terá um trabalho em mãos para alterar o esquema do banco de dados
    • Armazenamento - supondo que esta coluna seja VARCHAR, os requisitos de armazenamento serão maiores do que se os tipos de dados corretos fossem usados ​​(armazenar 1 ou 0 como um tipo de dados BIT custa 1 byte, VARCHAR custaria 3)
    • Dependendo do comprimento da coluna VARCHAR, isso pode aumentar enormemente a quantidade de memória necessária para executar consultas - se o SQL Server precisar classificar essa coluna, ele assume que cada linha contém um valor VARCHAR com metade do tamanho do comprimento varchar e usa essa estimativa para conceder a quantidade apropriada de memória. Se sua coluna for VARCHAR(MAX) e o otimizador de consulta precisar classificar essa coluna, seu servidor poderá ficar sem memória rapidamente e novas consultas terão que esperar até que as existentes sejam concluídas (conhecido como RESOURCE_SEMAPHORE waits)
    • É provável que você introduza conversões implícitas ao comparar a coluna com outra coisa, o que geralmente é ruim para estimativa e pode causar vários problemas de desempenho
    • Permissões - e se eu quiser que um usuário possa atualizar departamentos, mas não pessoas, mas ambos estão armazenados na mesma tabela?

    Quanto aos conceitos de design, as listas delimitadas por vírgulas violam a primeira forma normal e o OTLT potencialmente viola a segunda forma normal

    FWIW, eu vivi a dor que esses padrões causam e eles são apenas IMO desagradáveis. Convencer aqueles que os criaram a eliminá-los provavelmente exigirá testes que evidenciem os pontos acima - ao testar, não pense necessariamente em quantos dados você tem agora, pense em 1, 3, 5 anos

    • 1

relate perguntas