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

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

Ele deve ser projetado de forma que tudo fique no mesmo local ou é bom ter mais mesas?

Será que isso afetará alguma coisa?

Estou fazendo essa pergunta porque um amigo meu modificou alguma estrutura de banco de dados no mediaWiki. No final, em vez de 20 mesas, ele estava usando apenas 8, e levou oito meses para fazer isso (era 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.

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

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

As possíveis exceções podem ser ambientes peculiares que têm limites rígidos nos números das tabelas, mas não consigo pensar em um exemplo concreto de um sistema desse tipo.

Um banco de dados deve ter exatamente quantas tabelas for necessário. Nem menos, nem mais.

As tabelas de banco de dados devem aderir ao Princípio de responsabilidade única, da mesma forma que as classes. Cada tabela deve lidar com não mais de um grupo de dados relacionados para começar. Além do desempenho, isso facilita o gerenciamento de toda a fera, porque as próprias tabelas serão menores. Isso também oferece um melhor desempenho, porque as tabelas menores são mais rápidas para pesquisar e ingressar.

Não se preocupe com o número de tabelas, assim como não se preocupe com o número de classes - não se preocupe. Concentre-se em criar um código bom, limpo e legível, e não em quanto espaço ele ocupa. Refatorar agressivamente quando você tiver 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 que não são necessárias, etc. Crie um perfil para ver quais consultas estão demorando mais e por quê e resolva esses problemas se realmente forem um problema.

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 mais difícil de consultar, com problemas de integridade de dados e muito mais difícil de manter 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 sabe exatamente o que está fazendo e por quê. É muito fácil reduzir a desnomalização, portanto isso deve ser feito apenas por um especialista em banco de dados ou desenvolvedor sênior de aplicativos com anos de experiência em banco de dados. Uma pessoa inexperiente deve estar se esforçando para, no mínimo, alcançar a terceira forma normal (a menos que você esteja fazendo um data warehousing, que é uma área para a qual eu não consideraria contratar uma pessoa inexperiente) em qualquer banco de dados que ele / ela projetar.

Quando as pessoas dizem que reduzem as tabelas porque as junções são caras, geralmente ignoram ou têm bancos de dados mal projetados que não possuem índices críticos ou que usam grandes chaves naturais de colunas múltiplas. Os bancos de dados relacionais são projetados para usar junções e as junções podem ser bastante eficientes se os FKs forem indexados corretamente e usarem pequenos campos para ingressar (números inteiros são mais eficientes). Você observará 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 resolver de outra maneira (e existem várias maneiras de tentar antes de assumir o risco extenso de seus dados de desnormalizar uma tabela) .

Como todos os campos em um banco de dados são definidos 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-o em uma única tabela que armazena exatamente isso. Não é muito útil, mas inteiramente possível.

As tabelas são uma camada abstrata que ajuda nos problemas de lidar com dados. É por isso que eles são criados. Eu fiz uma piada, mas o entendimento de que você pode reduzir todo conjunto de dados para uma tabela mestre imediatamente indica por que não deveria: porque as tabelas trazem algo para você. Em um nível conceitual, eles oferecem uma estrutura que é mais fácil de entender para os seres humanos do que dados serializados. No nível intermediário, eles trazem o conceito de normalização: para evitar salvar dados redundantes e fornecer um único ponto para alterações, em vez de alterar algo em vários lugares. Em um nível técnico, os bancos de dados trazem a maioria das coisas que você deseja fazer com dados, inúmeras ferramentas, e as implementaram e as testaram mais do que você provavelmente fará. Pense em tipos de dados, valores padrão, direitos do usuário, índices, restrições de chave estrangeira etc. Foi testado, usado por muitos, otimizado, depurado. (Não em 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, trata-se das decisões corretas , em vez de apenas reduzir cegamente o número de tabelas.)

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

Ter o número mínimo de mesas me parece um objetivo muito peculiar.

Certamente, reduzir um esquema de 20 tabelas para 8 pode ser uma coisa boa (se bem feito, pode reduzir junções e aumentar o desempenho, remover colunas não utilizadas e assim por diante), mas também pode dificultar a compreensão e o aprimoramento no futuro.

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

Obviamente, isso também pode levar a um desempenho mais lento (supondo que o banco de dados desnormalizado tenha sido bem projetado).

Por fim, você precisa pensar em quais são seus requisitos nessas áreas, mas como uma posição inicial padrão, diria que busque um nível razoável de normalização e verifique se isso está causando problemas específicos, onde menos tabelas podem ser uma solução.

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

Juntamente com as preocupações com normalização e desempenho, você pode usar "que exigirá outra tabela" como uma maneira de gerenciar o escopo de um aplicativo. Esse recurso exigirá uma nova tabela e todo o tempo, energia e esforço para projetar, construir, testar, gerenciar nas atualizações e todas as outras codificações envolvidas. Adicionar 5 campos às tabelas existentes (quando apropriado) é muito mais fácil do que uma tabela de 5 colunas.

Se você projetar um banco de dados com a tentativa de minimizar a criação de tabelas, em breve verá a dificuldade abrupta e os erros.

A contagem de tabelas não deve estar na vanguarda de sua mente ao criar um design de banco de dados. Coloque as coisas onde elas precisam de forma lógica e relacional.

Acho que o número de tabelas é importante e pode ter um grande impacto no desempenho se você optar por dividir os dados que, para todos os fins e objetivos de negócios, permaneçam juntos em várias tabelas (ou seja, para que você tenha um banco de dados normalizado). Normalmente, quando você faz isso, é obrigado a JOIN Operations (ou equivalente não SQL) para obter todos os dados necessários e, para tabelas suficientemente grandes e estruturadas dessa maneira, o desempenho diminui rapidamente.

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

O mesmo poderia ser dito para servidores de pesquisa, como o Apache's Solr, que realmente não incentiva ou facilita a divisão de seus documentos em várias "tabelas" ou "tipos de entradas", incentivando você a ter um esquema "um engloba tudo" que possua campos em comum a todos os tipos de documento que você deseja indexar (e, consequentemente, evite executar operações semelhantes a JOIN).

Não estou dizendo que o simples fato de ter x tabelas em um esquema necessariamente o torne mais lento do que um esquema com tabelas x / 2 o tempo todo, mas há certos contextos nos quais isso pode levar a lentidão devido à consequente operações extras necessárias para agregar os dados em todas essas tabelas. Continuando com isso, também não acho aceitável dizer que "qualquer número de tabelas e a extrema normalização dos dados não afetam o desempenho de qualquer forma".

O tio Bob argumentaria que mais é mais simples.

Consulte http://c2.com/cgi/wiki?FearOfAddingTables

"um bom design é geralmente simplificado adicionando tabelas"

Acredito que quase todas as entidades são muitas para muitas, o que exige mais tabelas.

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

Então 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. Comercial
2. clientes

e ambos compartilham os mesmos estados (campos) e, portanto, 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 nos table_persons, precisaremos adicionar um novo campo (type_of_person).

Outro erro (erro que não é realmente necessário) é "dividir" uma tabela, lida como: separe 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 a ingressar em duas tabelas e isso é ruim.