Tabela única com mais colunas vs várias tabelas com menos colunas

8

Qual seria o melhor design de banco de dados para um site de rede social? Uma única tabela com mais colunas e menos linhas ou várias tabelas com menos colunas, mas mais linhas?

Por exemplo: Um usuário pode postar uma atualização em seu mural ou em um grupo.

Dois designs de banco de dados em que consigo pensar são:

Design 1

UserPosts

Eu iria
ID do usuário
postar
data hora

UserGroupPost :

Eu iria
groupId
ID do usuário
postar
data hora

Problema potencial : pode exigir junções, o que pode (no futuro) ser uma consulta lenta.

Design 2

Mensagens :

Eu iria
ID do usuário
groupId
postar
datetime (onde groupid seria nulo se o usuário postar em seu mural)

Problema em potencial : o loop em um conjunto de dados grande pode levar um tempo (longo).

Como posso obter um melhor desempenho quando os dados aumentam? Existe alguma outra maneira (melhor)?

mysql database-design

— Siddharth Patel
fonte

Para mim, poucas colunas mais linhas. É fácil gerenciar uma porção por porção do que ter um grande conjunto de dados. Se sua grande preocupação são os grandes dados no futuro, não. O servidor sql é projetado com esse tipo de problema, tudo que você precisa fazer é projetá-lo corretamente. Ter um grande conjunto de dados não é um problema se você sabe como otimizar sua consulta

— Vincent Dagpin

Usar o plano de execução é realmente uma grande ajuda. Ele informa qual é o problema da sua consulta. Ps: não fazer loop, se o processamento de utilização em massa possível, esse recurso já está lá, usá-lo

— Vincent Dagpin

2

Minha inclinação aqui seria sempre a opção 1 de design, ou pelo menos nesse sentido. Não se preocupe muito em tentar eliminar a necessidade de ingressar em tabelas em consultas futuras - qualquer banco de dados normalizado usará associações em quaisquer consultas úteis, isso é apenas bancos de dados relacionais.

Além disso, por que você necessariamente precisaria ingressar nas tabelas userPosts e userGroupPosts do seu site? Eles não seriam exibidos separadamente? O único motivo para você ingressar nessas tabelas é talvez ao pesquisar postagens, mas não deve ser muito difícil escrever consultas eficientes para isso. Além disso, você pode querer consultar as tabelas para fins de análise, mas esse não é o objetivo principal desse banco de dados.

O Design 2 pode, no mínimo, significar que você acaba com uma mesa muito ocupada.

A melhor opção seria prototipar cada um e executar alguns testes. Crie um protótipo de cada opção de design e faça alguns testes de desempenho em diferentes operações com alguns dados fictícios.

— Ian_H
fonte

-3

Para mim, conforme sua estrutura atual, o Design 2 é melhor. Você pode implementar o particionamento, a consulta otimizada e a maneira estruturada de criar banco de dados / tabela diminuirá o tempo de execução. Mas alguma normalização de caso funciona melhor, mas depende totalmente da arquitetura de design do banco de dados.

— Dipa
fonte