É necessário criar um banco de dados com o menor número de tabelas possível

51

Devemos criar uma estrutura de banco de dados com um número mínimo de tabelas?

Deve ser projetado de forma que tudo permaneça em um único lugar ou não há problema em ter mais tabelas?

Será que de alguma forma afetará alguma coisa?

Estou fazendo esta pergunta porque um amigo meu modificou algumas estruturas de banco de dados no mediaWiki. No final, em vez de 20 tabelas, ele estava usando apenas 8, e levou oito meses para fazer isso (foi a sua tarefa na faculdade).

EDITAR

Estou concluindo a resposta como: o tamanho das tabelas NÃO importa, até que o caso seja excepcional; Nesse caso, a desnormalização pode ajudar.

Obrigado a todos pelas respostas.

    
por Shaheer 13.06.2011 / 16:57
fonte

13 respostas

154

IGNORE o número de tabelas. Preocupe-se mais em obter o design correto. Se sua principal preocupação é a quantidade de tabelas, você provavelmente não deveria estar projetando sistemas de banco de dados.

Se o seu amigo precisou apenas de 8 tabelas e o sistema funciona bem com isso, então 8 é o número correto e os 12 restantes podem não ter sido necessários para o que ele estava fazendo.

Possíveis exceções podem ser ambientes peculiares que têm limites rígidos em números de tabelas, mas não consigo pensar em um exemplo concreto de tal sistema fora do meu limite.

    
por 13.06.2011 / 17:09
fonte
71

Um banco de dados deve ter exatamente quantas tabelas forem necessárias. Não menos, não mais.

    
por 13.06.2011 / 17:09
fonte
17

As tabelas de banco de dados devem aderir ao Princípio da Responsabilidade Única, assim como as classes devem. Cada tabela deve lidar com no máximo um grupo de dados relacionados para começar. Deixando de lado o desempenho, isso torna a fera mais fácil de gerenciar, porque as próprias tabelas serão menores. Isso também lhe dá melhor desempenho, porque tabelas menores são mais rápidas para pesquisar e participar.

Não se preocupe mais com o número de tabelas do que com o número de classes - não se preocupe. Concentre-se em criar um código bom, limpo e legível, não em como muito espaço que ocupa. Refatore de forma agressiva uma vez que você tenha um produto em funcionamento para torná-lo melhor - e eu também quero dizer o banco de dados! Você verá colunas que devem estar em outras tabelas, ou não são necessárias, etc. Perfil para ver quais consultas estão demorando mais e por quê, e resolva esses problemas se elas realmente forem um problema.

    
por 13.06.2011 / 17:13
fonte
7

Um banco de dados de produção para um aplicativo de negócios pode conter centenas ou até milhares de tabelas. Você precisa do número de tabelas necessárias para os requisitos de negócios. Tentar reduzir o número de tabelas apenas por ter menos tabelas geralmente resultará em um banco de dados que é mais difícil de consultar, tem problemas de integridade de dados e é muito mais difícil de gerenciar do que um banco de dados normalizado.

Há momentos em que a desnormalização é necessária. Isso só deve ser feito por alguém que saiba exatamente o que está fazendo e por quê. É muito fácil acabar com a denomalização, por isso só deve ser feito por um especialista em banco de dados ou desenvolvedor de aplicativos sênior com anos de experiência em banco de dados. Uma pessoa inexperiente deve estar se esforçando para, no mínimo, atingir a terceira forma normal (a menos que você esteja fazendo o armazenamento de dados, que é uma área que eu não consideraria contratar uma pessoa inexperiente para) em qualquer banco de dados que ele / ela projete. >

Quando as pessoas dizem que reduzem as tabelas porque as junções são caras, elas geralmente são ignorantes ou possuem bancos de dados mal projetados que estão faltando índices críticos ou usam chaves naturais de grandes colunas múltiplas. Bancos de dados relacionais são projetados para usar joins e joins podem ser bastante eficientes se os FKs estiverem corretamente indexados e eles usarem campos pequenos para serem unidos (os inteiros são mais eficientes). Você notará que as grandes empresas que possuem bancos de dados do tamanho de terrabytes conseguem, de alguma forma, obter excelente desempenho e usar junções.

Nenhum designer de banco de dados sério tenta reduzir o número de tabelas apenas porque deseja menos tabelas. Você reduz o número de tabelas porque os dados não são mais necessários ou você tem um problema de desempenho que não pode ser resolvido de outra maneira (e há muitas maneiras de tentar antes de assumir o risco extenso ) seus dados de desnormalizar uma tabela).

    
por 13.06.2011 / 18:17
fonte
5

Como cada campo em um banco de dados é definido pela combinação de nome da tabela, nome da coluna, chave primária e valor, você sempre pode reduzir o número de tabelas desnormalizando em uma única tabela que armazena apenas isso. Não é muito útil, mas inteiramente possível.

As tabelas são uma camada abstrata que ajuda com as questões de lidar com dados. É por isso que eles são criados. Eu fiz uma piada, mas entender que você pode reduzir cada conjunto de dados para uma tabela mestre imediatamente aponta porque você não deveria: porque as tabelas lhe trazem algo. Em um nível conceitual, eles trazem para você uma estrutura que é mais fácil de entender para os humanos do que os dados serializados. No nível intermediário, eles trazem o conceito de normalização: para evitar salvar dados redundantes e dar um único ponto para mudanças, em vez de mudar algo em vários lugares. Em um nível técnico, bancos de dados trazem a maioria das coisas que você quer fazer com dados, várias ferramentas, e as implementaram e testaram mais do que você provavelmente faria por si mesmo. Pense em tipos de dados, valores padrão, direitos de usuário, índices, restrições de chaves estrangeiras, etc. Ele foi testado, usado por muitos, otimizado, depurado. (Não na perfeição, mas ainda assim.)

Como um banco de dados é uma ferramenta, o principal é decidir como usar a ferramenta. O número de tabelas não é importante. Minimizar é sempre possível, mas ao custo de jogar fora os benefícios. (Se você ler mais sobre normalização, encontrará alguns casos de desnormalização - mas mesmo assim é tudo sobre as decisões certas em vez de apenas reduzir cegamente o número de tabelas.)

    
por 13.06.2011 / 19:34
fonte
3

Você deve usar o número de tabelas correto . Você poderia, em teoria, se contentar com uma única tabela de tabelas, desnormalizando o banco de dados inteiro, mas o banco de dados estaria inutilizável. Seu amigo parece que ele tem muito tempo em suas mãos.

    
por 13.06.2011 / 17:09
fonte
2

Ter o número mínimo de tabelas parece-me uma meta muito peculiar.

Certamente, reduzir um esquema de 20 para 8 pode ser bom (se bem feito, pode reduzir as junções e aumentar o desempenho, remover colunas não usadas, etc.), mas também pode dificultar a compreensão e o aprimoramento no futuro. .

Para pensar nisso de outra maneira você acha que a normalização é uma coisa boa? A normalização geralmente leva a um maior número de tabelas, mas também leva a soluções mais fáceis de manter, redução da duplicação de dados e gerenciamento de dados mais fácil.

Claro que também pode levar a um desempenho mais lento (assumindo que o banco de dados desnormalizado foi bem projetado).

Em última análise, você precisa pensar sobre quais são os seus requisitos nessas áreas, mas como uma posição inicial padrão eu diria que vai para um nível razoável de normalização e, em seguida, verificar se isso está causando problemas específicos onde menos tabelas podem ser uma solução.

    
por 13.06.2011 / 17:25
fonte
0

O número não é importante. O design é. Veja alguns sistemas por aí. Magento, PHPBB, etc. Eles têm dezenas de tabelas em seus sistemas e funcionam muito bem.

    
por 13.06.2011 / 23:55
fonte
0

Além das preocupações com a normalização e o desempenho, você pode usar "que exigirá outra tabela" como forma de gerenciar o escopo de um aplicativo. Esse recurso exigirá uma nova tabela e todo o tempo, energia e esforço para projetar, criar, testar, gerenciar os upgrades e todos os outros códigos envolvidos. Adicionar 5 campos à (s) tabela (s) existente (s) (quando apropriado) é muito mais fácil que uma tabela de 5 colunas.

    
por 05.08.2011 / 21:53
fonte
0

Se você criar um banco de dados tentando minimizar a criação de tabelas, logo verá a dificuldade abrupta e errará seus caminhos.

A contagem de tabelas não deve estar na vanguarda ao criar um design de banco de dados. Coloque as coisas onde elas precisam logicamente e relacionalmente.

    
por 05.08.2011 / 23:08
fonte
0

Acho que o número de tabelas é importante e pode ter um grande impacto no desempenho se você optar por dividir os dados que devem, para todos os objetivos e propósitos de negócios, permanecer juntos em várias tabelas (ou seja, você teria um banco de dados de normalização ). Normalmente, quando você faz isso, você será forçado a JOIN Operations (ou equivalente não-SQL) para obter todos os dados que você precisa e para tabelas grandes o suficiente, estruturadas como essa, o desempenho desce rápido.

Não vou entrar em detalhes, mas acho que o fato real de que o número de tabelas pode influenciar o desempenho é uma das razões pelas quais bancos de dados noSQL como Cassandra, Mongo e Google BigTable (sic!) têm foram inventados, e é também por isso que eles incentivam a desnormalização de dados (e consequentemente evitam um grande número de tabelas / coleções, etc.).

O mesmo pode ser dito para servidores de pesquisa como o Solr do Apache, que não incentiva ou facilita facilmente a divisão de documentos em várias "tabelas" ou "tipos de entradas", incentivando você a ter um esquema "um que engloba tudo" possui campos comuns a todos os tipos de documentos que você deseja indexar (e, consequentemente, evitar ter que executar operações semelhantes a JOIN).

Não estou dizendo que o simples fato de ter x tabelas em um esquema necessariamente tornará mais lento que um esquema com tabelas x / 2 todas as vezes, mas há certos contextos nos quais ele pode levar a lentidões devido às operações extras consequentes necessárias para agregar os dados em todas essas tabelas. Continuando com isso, eu também não acho que seja correto dizer que "qualquer número de tabelas e extrema normalização dos dados não tem impacto algum sobre o desempenho".

    
por 04.10.2012 / 17:39
fonte
0

O tio Bob argumentaria que Mais é mais simples.

Veja o link

"um bom design é geralmente simplificado pela adição de tabelas"

Acredito que quase todas as entidades são de muitos para muitos, o que requer mais tabelas.

Crie uma tabela de países com o código continente. Ah, você não pode porque na verdade existem 8 países transcontinentais. Mesmo com moedas. Panamá usa dois.

    
por 06.10.2014 / 23:31
fonte
-2

A resposta é SIM.

Mas dependa qual é o verdadeiro significado do número "mínimo" de tabelas.

Por exemplo (um anti-exemplo).

Se eu tiver os próximos objetos

  1. usuários
  2. clientes

e ambos compartilham os mesmos estados (campos) e não há uma restrição de segurança, é mais adequado para fazer uma única tabela

  1. table_persons

em vez de duas tabelas diferentes

  1. table_users
  2. table_customers

os contras são do que em table_persons precisaremos adicionar um novo campo (type_of_person).

Outro erro (erro, se não é realmente necessário) é "dividir" uma tabela, como: separar uma única tabela em duas.

  1. table_persons

em duas tabelas

  1. table_info_persons
  2. table_extra_info_persons

porque você está forçando algumas consultas para juntar duas tabelas e isso é ruim.

    
por 13.06.2011 / 22:50
fonte