Cuidados com modelagem para muitos registros

[paulo_roll 0]

Bom dia, pessoal.

 

Estou a criar um sistema de posts e likes e tudo que será postado ficará na tabela post.

Na tabela like terei os campos id_like, id_usuario, id_post.

 

Gostaria de saber se as tabela posts e a tabela like atingirem média de 500 mil registros, 800 mil registros,

na hora de eu dar um SELECT tem risco de travar o sistema ou ficar lento demais?

 

Óbvio que usarei filtros como WHERE na tabela like para exibir somente os likes do id daquele post.

e na tabela posts usarei paginação.

 

Mas o fato de ter 500 mil registros, o where e paginação não escaneiam o banco de dados todo?

Isso pode ficar pesado?

[-=Érico=- 5]

Olá Paulo,

Isso pode variar sensívelmente dependendo de como a sua tabela está estruturada.

Dependendo de quantos acessos o banco de dados terá simultaneamente um servidor com 2-4GB de memória RAM consegue suportar tranquilamente.

 

Referente ao SELECT, pode ficar pesado ou não, se a coluna que você usar é índice (INDEX), o banco de dados não irá buscar todos os registros, a consulta será extremamente rapida caso você busque um registro usando a primary key por exemplo.

[paulo_roll 0]

Opa!

 

Sim tudo que faço no banco de dados é criando um campo id_algumacoisa auto numeração.

Os SELECTS sempre possuem um WHERE id_algumacoisa para filtrar, porem algumas coisas andei pensando em otimizar...

 

Exemplo:

Quero saber o numero de posts de um usuário na tabela POSTS

poderia até fazer um SELECT * FROM posts WHERE id_usuario = '$id_usuario' e depois aplicar o mysql_num_rows

que me retornaria o numero de linhas que no caso seria o numero de posts.

 

Mas uma forma que acredito que gaste menos memória e a modelagem usada até no phpbb, é de ao inserir um registro na

tabela POST, eu ir na tabela USUARIOS e lá ter um campo chamado NUMERO_POSTS e dar um update somando mais um

na hora do INSERT. Se excluir subtrai e após fazer isso fazer uma sincronia uma vez só onde eu pego o ID do USUARIO,

faço o metodo mais lento de mandar contar tudo na tabela POSTS e pego o resultado do mysql_num_rows que vai mostrar

quantos posts existem e dou um UPDATE la na tabela desse USUARIO informando no bd quantos posts ele tem.

 

depois para mostrar ao publico o numero de posts do usuario basta eu resgatar os dados desse usuario como nome e numero_posts

na tabela usuarios.

 

Acredito que gaste bem menos memória. Até o phpbb tem o botão sincronizar e a estrutura de banco de dados é assim.

 

Obrigado pela contribuição e como estava pensando ao mesmo tempo que postei, dividi a solução com todos aqui do forum.

 

Ah e se houver alguma objeção, me avisa pra eu não fazer uma modelagem problemática hehehee

 

Abs.

[paulojuchem 20]

se voce quer um simples count de likes, eu sugiro uma tabela separada com os valores somados nela, dai tu cria um evento de X tempo para atualizar essa tabela, o youtube deve fazer algo semelhante

[Motta 645]

Poderia ser avaliado esta contagem ser feita via trigger.

 

Avaliar também soluçøes NoSQL.

[paulo_roll 0]

se voce quer um simples count de likes, eu sugiro uma tabela separada com os valores somados nela, dai tu cria um evento de X tempo para atualizar essa tabela, o youtube deve fazer algo semelhante

Sim. No caso seria uma sincronia de dados.

Quanto ao evento para fazer isso acho melhor fazer logo depois do INSERT, DELETE ou UPDATE.

 

O sistema sincroniza tudo daquele usuário naquele momento, selecionando o número de posts dele e jogando o resultado

na tabela USER no campo NUMERO_POSTS.

 

A forma clássica de dar um mysql_num_rows na pagina publica pode trazer sérias dores de cabeça quando o sistema

estive sendo muito utilizado. Melhor então fazer essa sincronia nos eventos INSERT, DELETE e UPDATE.

 

O SELECT só mostraria o resultado já armazenado.

 

Mas agora surgiu uma dúvida.

Se eu quiser exibir o nome de todos que deram o like, terei de ir na tabela like e dar um SELECT * FROM like WHERE id_post = '$id_post'

 

Em seguida pegar o id dos usuarios e selecionar o nome deles na tabela USER para exibir.

 

Existe alguma forma de eu criar uma coluna USERS_CURTIRAM na tabela POSTS e nessa colunar armazenar

todos os IDs dos usuários. Mas aí terei que mecher com array e serialize?

[paulojuchem 20]

esse evento é um `evento` no mysql, olha aqui http://dev.mysql.com/doc/refman/5.1/en/create-event.html

 

manda ele atualizar a cada 1h por exemplo