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

52

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.

Shaheer
fonte
15
O número mínimo de tabelas é fácil, basta serializar o todo para master_table (table_name, col_name, col_type, row_id, value).
Inca
o que? Eu não estou entendendo #
6266
12
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.
Inca
bem, eu estava pedindo por saber, e se algo é menos útil do que o existente, por que incomodá-lo? Quero dizer, isso proporcionará alguma melhoria em alguma coisa? desempenho por exemplo?
Shaheer
11
@Hamza: Ele pode fornecer um melhor desempenho. Realmente depende das circunstâncias específicas. Não há quase bastante informação aqui para nos fornecer uma resposta concreta.
FrustratedWithFormsDesigner

Respostas:

155

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.

FrustratedWithFormsDesigner
fonte
107
1:If your major concern is quantity of tables, you should probably not be designing database systems.
Joel Etherton 13/06
9
Corolário: uma tabela de banco de dados não ocupa [muito] espaço extra. São os dados que ocupam espaço. Normalização = mais tabelas = menos repetição = menos espaço usado. Ao tentar minimizar o número de tabelas, você não apenas compromete o design, mas também perde espaço . Esse "jogo de mesa" é ruim ao redor, a menos que algumas das mesas sejam literalmente redundantes.
Aaronaught
11
+1, embora eu não pense que sabemos o suficiente para dizer que o número correto é 8 no caso dele, pois não podemos comparar os esquemas (o original pode resistir melhor a um volume transacional maior do que o aplicativo atualmente, por exemplo)
Adam Robinson
2
@ Hamza: Ok, então ele pode ter boas habilidades em PHP e banco de dados, e esse projeto pode exigir os dois - mas não faça a suposição de que ter um implica automaticamente no outro. Muitos desenvolvedores podem ter uma habilidade, mas não a outra.
FrustratedWithFormsDesigner
4
@ Tom Anderson - Então você ainda não deveria estar projetando sistemas de banco de dados.
Joel Etherton
71

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

Adam Crossland
fonte
3
english.stackexchange.com/questions/495/less-vs-fewer Não transformar isso em discussão, mas aqui está uma discussão interessante sobre o debate "menos" vs. "menos", incluindo suas origens, do idioma inglês SE , já que parece entusiasmar vocês;) #
Corey
17

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.

Michael K
fonte
4
Em um modelo de dados normalizado, sim, essa é a melhor abordagem, no entanto, se o banco de dados for destinado a relatórios ou acesso de leitura principalmente, as tabelas "achatadas" desnormalizadas terão um desempenho melhor em grandes conjuntos de dados. Um número menor de tabelas nesse caso resultará em menos junções e melhor desempenho.
Maple_shaft
2
@ maple Concordo absolutamente. Você precisa criar um perfil para determinar quais conjuntos de dados precisam ser agrupados; portanto, na IMO, você precisa começar a normalizar. YMMV, os especialistas provavelmente podem fazer isso de cabeça para baixo :) Jeff tem um post sobre desnormalização que você também pode achar interessante.
Michael K
11
Bom e sucinto post, eu já li este antes! Às vezes, você pode aproveitar o melhor dos dois mundos. Se o relatório não precisar ser 100% em tempo real, mantenha dois esquemas, um esquema principal sendo o esquema normalizado transacional para uso do aplicativo e o outro um esquema desnormalizado que é transmitido regularmente e adaptado para o acesso a dados de relatório.
Maple_shaft
11
Mais informações sobre o assunto com uma explicação do Star Schema: publib.boulder.ibm.com/infocenter/rbhelp/v6r3/…
maple_shaft
11
@ maple_shaft, eu concordo que o banco de dados de relatórios é frequentemente desnomalizado para desempenho, mas não é algo que eu esperaria que um estudante ou programador júnior pudesse assumir. Sei que certamente não permitiria que meus data warehouses fossem manipulados por qualquer pessoa que não tivesse experiência comprovada.
HLGEM
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 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) .

HLGEM
fonte
O Google projetou o BigTable e excluiu deliberadamente as junções, pois não é paralelamente agradável.
Lie Ryan
2
@ Ryan Ryan, BigTable é um caso especial que NÃO é apropriado para a maioria dos aplicativos de negócios, pois a integridade dos dados não é uma grande preocupação. O Google não precisa de muitas regras comerciais complexas para pesquisar. Aposto que o aplicativo financeiro corporativo não usa o BigTable. No entanto, a maioria dos aplicativos de negócios que possuem grandes bancos de dados pode, de fato, usar junções e ter um bom desempenho se o designer for qualificado. Os bancos de dados corporativos têm várias maneiras de melhorar o desempenho (incluindo o particionamento) e, portanto, não precisam perder os recursos de integridade de dados de um banco de dados relacional.
HLGEM 13/06
+1 para você, @HLGEM, tanto pela resposta quanto pelo comentário; é uma pena ver muitos desenvolvedores que saltam para a onda do banco de dados de documentos porque pensam em "junções = lentas", apenas para tentar resolver problemas relacionais que foram resolvidos por bancos de dados relacionais há 20 anos.
Adam Robinson
5

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.)

Inca
fonte
graças, que é muito claro agora !, e eu li sobre a normalização btw, i fazê-lo ele mesmo em bancos de dados CakePHP, que incentiva o outro e um pouco diferente abordagem.
Shaheer
3

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.

Neil Butterworth
fonte
2

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.

Jon Hopkins
fonte
0

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.

Ryan Street
fonte
0

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.

JeffO
fonte
0

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.


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, 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".

Shivan Dragon
fonte
0

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.

Neil McGuigan
fonte
-2

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.

Magallanes
fonte
ei, sua resposta é muito descritiva e está ajudando, obrigado #
214
2
Isso me dá flashbacks do meu primeiro aplicativo corporativo e do banco de dados por trás dele, e o pesadelo que o DBA fez de ser um nazista da mesa em coisas como essa. Eu absolutamente nunca uniria clientes e usuários, essas são entidades de negócios totalmente diferentes.
-1: usuários e clientes têm campos diferentes; Se não, neste momento, eles terão em algum momento no futuro. Então eles merecem tabelas separadas.
precisa
11
@ Sjoerd, @ Chris: Embora esse possa ser o caso, não é necessariamente verdade. Coisas assim dependem da aplicação. Dito isto, concordo com o sentimento. Com muita frequência, os desenvolvedores de bancos de dados verão "nomes de campos comuns" significa que são os mesmos dados. Isso se torna especialmente fácil quando você olha o banco de dados a partir do ORM primeiro (em outras palavras, ao contrário). Embora os conceitos de OO possam ser modelados no banco de dados, os bancos de dados são linhas e relações, não objetos .
Adam Robinson
11
+1 para "bancos de dados são linhas e relações, não objetos", vou adicioná-lo às minhas citações favoritas!
Shaheer