Qual é o melhor design de banco de dados:mais tabelas ou mais colunas?[fechado]

https://stackoverflow.com/questions/59482

09-06-2019
|

Pergunta

Um ex-colega de trabalho insistiu que um banco de dados com mais tabelas e menos colunas cada é melhor do que um banco de dados com menos tabelas e mais colunas cada.Por exemplo, em vez de uma tabela de clientes com nome, endereço, cidade, estado, CEP, etc.colunas, você teria uma tabela de nomes, uma tabela de endereços, uma tabela de cidades, etc.

Ele argumentou que esse design era mais eficiente e flexível.Talvez seja mais flexível, mas não estou qualificado para comentar a sua eficiência.Mesmo que seja mais eficiente, penso que esses ganhos podem ser compensados pela complexidade adicional.

Então, há algum benefício significativo em mais tabelas com menos colunas em vez de menos tabelas com mais colunas?

Solução

Tenho algumas regras práticas bastante simples que sigo ao projetar bancos de dados, que acho que podem ser usadas para ajudar a tomar decisões como esta....

Favorecer a normalização.A desnormalização é uma forma de otimização, com todas as compensações necessárias e, como tal, deve ser abordada com uma abordagem YAGNI atitude.
Certifique-se de que o código do cliente que faz referência ao banco de dados esteja suficientemente dissociado do esquema para que sua reformulação não exija uma grande reformulação do(s) cliente(s).
Não tenha medo de desnormalizar quando isso proporcionar um benefício claro ao desempenho ou à complexidade da consulta.
Use visualizações ou tabelas downstream para implementar a desnormalização em vez de desnormalizar o núcleo do esquema, quando o volume de dados e os cenários de uso permitirem.

O resultado usual dessas regras é que o design inicial irá favorecer tabelas em vez de colunas, com foco na eliminação de redundância.À medida que o projeto avança e os pontos de desnormalização são identificados, a estrutura geral evoluirá em direção a um equilíbrio que comprometa a redundância limitada e a proliferação de colunas em troca de outros benefícios valiosos.

Outras dicas

Eu argumentaria a favor de mais mesas, mas apenas até certo ponto.Usando seu exemplo, se você separou as informações do usuário em duas tabelas, digamos USERS e ADDRESS, isso lhe dará a flexibilidade de ter vários endereços por usuário.Uma aplicação óbvia disso é um usuário que possui endereços de cobrança e envio separados.

O argumento a favor de ter uma tabela CITY separada seria que você só precisa armazenar o nome de cada cidade uma vez e consultá-lo quando precisar.Isso reduz a duplicação, mas neste exemplo acho um exagero.Pode ser mais eficiente em termos de espaço, mas você pagará o preço em junções ao selecionar dados do seu banco de dados.

Não parece tanto uma pergunta sobre tabelas/colunas, mas sobre normalização.Em algumas situações apresentam um alto grau de normalização ("mais tabelas" neste caso) é bom e limpo, mas normalmente é necessário um grande número de JOINs para obter resultados relevantes.E com um conjunto de dados grande o suficiente, isso pode prejudicar o desempenho.

Jeff escreveu um pouco sobre isso em relação ao design do StackOverflow.Veja também a postagem para a qual Jeff tem links de Ouse Obasanjo.

Um design totalmente normalizado (ou seja, "Mais tabelas") é mais flexível, mais fácil de manter e evita a duplicação de dados, o que significa que a integridade dos seus dados será muito mais fácil de aplicar.

Essas são razões poderosas para normalizar.Eu escolheria normalizar primeiro e depois desnormalizar específico tabelas depois você viu que o desempenho estava se tornando um problema.

Minha experiência é que, no mundo real, você não chegará ao ponto em que a desnormalização seja necessária, mesmo com conjuntos de dados muito grandes.

Depende do tipo do seu banco de dados.O MS SQL Server, por exemplo, tende a preferir tabelas mais estreitas.Essa também é a abordagem mais “normalizada”.Outros motores podem preferir o contrário.Os mainframes tendem a se enquadrar nessa categoria.

Cada tabela deve incluir apenas colunas pertencentes à entidade identificada exclusivamente pela chave primária.Se todas as colunas do banco de dados forem atributos da mesma entidade, você precisará apenas de uma tabela com todas as colunas.

Porém, se alguma das colunas puder ser nula, você precisará colocar cada coluna anulável em sua própria tabela com uma chave estrangeira na tabela principal para normalizá-la.Este é um cenário comum, portanto, para um design mais limpo, é provável que você adicione mais tabelas do que colunas às tabelas existentes.Além disso, ao adicionar esses atributos opcionais à sua própria tabela, eles não precisariam mais permitir nulos e você evitaria uma série de problemas relacionados a NULL.

O banco de dados multitabelas é muito mais flexível se qualquer um desses relacionamentos um para um puder se tornar um para muitos ou muitos para muitos no futuro.Por exemplo, se você precisar armazenar vários endereços de alguns clientes, será muito mais fácil se você tiver uma tabela de clientes e uma tabela de endereços.Eu realmente não consigo ver uma situação em que você precise duplicar algumas partes de um endereço, mas não outras, então tabelas separadas de endereço, cidade, estado e CEP podem ser um pouco exageradas.

Como todo o resto:depende.

Não existe uma regra rígida e rápida em relação à contagem de colunas versus contagem de tabelas.

Se seus clientes precisam ter vários endereços, faz sentido criar uma tabela separada para isso.Se você tiver um bom motivo para normalizar a coluna Cidade em sua própria tabela, isso também pode ser feito, mas nunca vi isso antes porque é um campo de formato livre (geralmente).

Um design normalizado e pesado de mesa é eficiente em termos de espaço e parece "bom como um livro didático", mas pode se tornar extremamente complexo.Parece bom até que você precise fazer 12 junções para obter o nome e o endereço de um cliente.Esses desenhos não são automaticamente fantástico em termos de desempenho que mais importa:consultas.

Evite a complexidade, se possível.Por exemplo, se um cliente puder ter apenas dois endereços (não muitos arbitrariamente), talvez faça sentido mantê-los todos em uma única tabela (CustomerID, Name, ShipToAddress, BillingAddress, ShipToCity, BillingCity, etc.).

Aqui está a postagem de Jeff sobre o assunto.

Há vantagens em ter tabelas com menos colunas, mas você também precisa analisar o cenário acima e responder a estas perguntas:

O cliente poderá ter mais de 1 endereço?Caso contrário, não será necessária uma tabela separada para endereços.Nesse caso, uma tabela separada se torna útil porque você pode adicionar facilmente mais endereços conforme necessário no futuro, onde fica mais difícil adicionar mais colunas à tabela.

eu consideraria a normalização como o primeiro passo, então cidades, condados, estados, países seriam melhores como colunas separadas...o poder da linguagem SQL, junto com os atuais DBMS-es, permite que você agrupe seus dados posteriormente, se precisar visualizá-los em alguma outra visualização não normalizada.

Quando o sistema estiver sendo desenvolvido, você pode considerar 'desnormalizar' alguma parte se considerar isso uma melhoria.

Acho que o equilíbrio está em ordem neste caso.Se faz sentido colocar uma coluna em uma tabela, coloque-a na tabela; se não, não faça.A abordagem de seus colegas de trabalho definitivamente ajudaria a normalizar o banco de dados, mas isso pode não ser muito útil se você precisar unir 50 tabelas para obter as informações necessárias.

Acho que minha resposta seria: use seu bom senso.

Há muitos lados nisso, mas do ponto de vista da eficiência do aplicativo, muitas tabelas podem ser mais eficientes às vezes.Se você tiver algumas tabelas com um monte de colunas toda vez que o banco de dados fizer uma operação, ele terá a chance de fazer um bloqueio, mais dados ficarão indisponíveis durante o bloqueio.Se os bloqueios forem escalados para páginas e tabelas (espero que não para tabelas :)), você poderá ver como isso pode tornar o sistema mais lento.

Hum.

Eu acho que é uma lavagem e depende do seu modelo de design específico.Definitivamente, fatore entidades que tenham mais do que alguns campos em sua própria tabela, ou entidades cuja composição provavelmente mudará conforme os requisitos do seu aplicativo mudam (por exemplo - eu fatoraria o endereço de qualquer maneira, já que ele tem tantos campos, mas eu 'd especialmente faça isso se achar que há alguma chance de precisar lidar com endereços de países estrangeiros, que podem ter um formato diferente.O mesmo com números de telefone).

Dito isto, quando estiver funcionando, fique de olho no desempenho.Se você desmembrou uma entidade que exige junções grandes e caras, talvez seja uma decisão de design melhor transformar essa tabela de volta no original.

Existem enormes benefícios consultas usando o mínimo de colunas possível.Mas a tabela em si pode ter um número grande. Jeff diz algo sobre isso também.

Basicamente, certifique-se de não pedir mais do que o necessário ao fazer uma consulta - o desempenho das consultas está diretamente relacionado ao número de colunas solicitadas.

Acho que você precisa observar o tipo de dados que está armazenando antes de tomar essa decisão.Ter uma tabela de endereços é ótimo, mas apenas se a probabilidade de várias pessoas compartilharem o mesmo endereço for alta.Se cada pessoa tivesse endereços diferentes, manter esses dados em uma tabela diferente apenas introduziria junções desnecessárias.

Não vejo vantagem em ter uma tabela de cidades, a menos que as cidades sejam entidades importantes para você em seu aplicativo.Ou se quiser limitar o número de cidades disponíveis para seus usuários.

O resultado final é que decisões como essa devem levar em consideração o próprio aplicativo antes de começar a buscar eficiência.OMI.

Ao projetar seu banco de dados, você deve estar o mais próximo possível do significado dos dados e NÃO da necessidade do seu aplicativo!

Um bom design de banco de dados deve permanecer inalterado por mais de 20 anos.

Um cliente pode ter vários endereços, essa é a realidade.Se você decidiu que seu aplicativo está limitado a um endereço para o primeiro lançamento, a preocupação é com o design do seu aplicativo, não com os dados!

É melhor ter várias tabelas em vez de várias colunas e usar a visualização se quiser simplificar sua consulta.

Na maioria das vezes, você terá problemas de desempenho com um banco de dados, trata-se de desempenho de rede (consulta em cadeia com resultado de uma linha, coluna de busca desnecessária, etc.) e não da complexidade de sua consulta.

Primeiro, normalize suas tabelas.Isso garante que você evite dados redundantes, proporcionando menos linhas de dados para verificar, o que melhora suas consultas.Então, se você chegar a um ponto em que as tabelas normalizadas que você está unindo estão fazendo com que a consulta demore muito para ser processada (cláusula de junção cara), desnormalize onde for mais apropriado.

É bom ver tantas respostas inspiradoras e bem fundamentadas.

Minha resposta seria (infelizmente):depende.

Dois casos:* Se você criar um modelo de dados que será usado por muitos anos e, portanto, possivelmente terá que se adaptar a muitas mudanças futuras:opte por mais tabelas e menos linhas e uma normalização bastante rigorosa.* Em outros casos você pode escolher entre mais linhas sem tabelas ou menos tabelas com mais linhas.Especialmente para pessoas relativamente novas no assunto, esta última abordagem pode ser mais intuitiva e fácil de compreender.

O mesmo é válido para a escolha entre a abordagem orientada a objetos e outras opções.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow