Estou tentando criar um esquema de banco de dados que será usado para uma rede social semelhante à do Facebook.
Pois poststenho dois esquemas em mente que são os seguintes:
- Design de tabela única
Nesta abordagem, haverá apenas uma tabela única para todos os tipos de postagem (texto, foto, vídeo etc.).
A estrutura pode ser semelhante à seguinte:
|-----------------------------------------------|
| id | user_id | type | content | ... |
|-----------------------------------------------|
A contentcoluna conterá os json_encodeddados para todos os tipos de mídia.
- Projeto de
várias tabelas Essa abordagem consideraria tabelas diferentes para cada tipo de mídia, que será uma tabela principal que contém o registro de postagem principal e cada tabela orientada à mídia conterá os respectivos dados de mídia.
Tabela de postagens:
|-----------------------------------------------|
| id | user_id | type | content | ... |
|-----------------------------------------------|
Tabela de fotos:
|------------------------------------------------------------|
| id | post_id | user_id | url | thumb_url | ... |
|------------------------------------------------------------|
Tabela de vídeos:
|-----------------------------------------------------------------|
| id | post_id | user_id | url | screenshot_url | ... |
|-----------------------------------------------------------------|
e assim por diante...
Eu ficaria muito feliz se você pudesse me orientar sobre qual abordagem é melhor ou qualquer outro esquema que serviria ao propósito em melhores condições, em termos de desempenho.
Como em todos os projetos de banco de dados, não pense apenas no que deseja armazenar, mas também em como deseja recuperar e modificar as informações .
Se você nunca precisar consultar ou pesquisar por partes individuais do conteúdo, seu primeiro esquema é adequado. Da mesma forma, se você precisar fazer essas coisas, mas estiver processando um banco de dados que permite indexação e manipulação eficientes de blocos JSON.
Como regra geral, porém, eu normalizaria os dados, o que significa dividi-los como você faz em tabelas separadas, em vez de usar uma coluna para armazenar muitos valores.
BTW: o padrão que você parece estar seguindo em seu segundo exemplo é chamado de herança de tabela - você tem um objeto "posts" geral que contém propriedades comuns a todos os seus tipos de objeto e uma tabela de detalhes para cada objeto contendo propriedades que são exclusivas para isso objeto (ou pelo menos não são comuns a outros tipos de objeto). A menos que uma postagem possa conter várias fotos (ou vídeos ou ...) o que está implícito em seu primeiro design, você não precisa de um ID separado para cada tabela de detalhes: haverá zero ou uma linha por linha,
postsportanto,post_idé válido como chave primária e chave estrangeira. Além disso, não há necessidade de repetiruser_idem cada tabela (pois isso pode ser derivado do link paraposts), a menos que um usuário diferente possa adicionar ophoto/videoao existente de outra pessoapost.