Logica de sistema em php com mysql muito grande

[DuuuuDuuuu 1]

Eu quero montar um sistema que em média vai ter 50 usuários, e para cada usuário vai ter em média 5 mil produtos cadastrados e 100 categorias, as tabelas seriam algo assim

 

tabela: usuarios

|id|user|senha|

 

tabela: produtos

|id|categoria|nome|

 

tabela: categoria

|id|nome|

 

mas se ficar assim, com 50 usuarios e cada um com media de 5 mil produtos e 100 categorias, iriar ter 250 mil produtos cadastrados e 5 mil categorias, oq ia deixar uma consulta bem demorada, mas tem sistemas gigantescos que usam alguma forma pra agilizar isso, no meu caso eu prescisaria para agilizar a consula de produtos por usuarios,

e não tenho a minima ideia doque pode me ajudar nisso, achei na internet algo sobre join do mysql e o usso do mysqli no lugar de mysql oq agilizo muito a busca de produtos por categoria. se alguem puder me ajudar, fico grato.

[mad.onion 0]

Existem várias técnicas para se agilizar consulta em banco de dados. No seu caso, 250 mil registros não é tão grande assim e dá pra resolver com um índice composto, além do da chave primária.

 

Se você conhece como funcionam os índices em bancos de dados, você pode agilizar essa pesquisa, no seu caso (produtos x usuário) criando um índice na tabela de produtos, composto pelo código do usuário (esse em primeiro lugar, -- imagino que terá o código de usuário na tabela de produtos, já que é isso que você passou) e em seguida, o código do produto. Coloque junto deste índices, as colunas que você mais vai utilizar, no caso, pode colocar também o nome do produto e o código da categoria.

 

Espero ter ajudado.

 

[]s

[criatividade zero 17]

pense no caso de aumento de usuarios, 100, 500, 1000... usuarios

to acompanhando o caso

[mad.onion 0]

Bem, ele disse que em média vão haver 50 usuários. Se o número de usuários começar a crescer, aí já acho que caberia um particionamento horizontal para resolver o problema. Mas até onde eu pude entender, ele disse 50 usuários em média.

[criatividade zero 17]

sim... 50 em media

e eu propus outra situação

 

ja havia lido sobre esse particionamento horizontal, mas nao achei absolutamente nada mais a fundo

como funciona esse particionamento?

[mad.onion 0]

sim... 50 em media

e eu propus outra situação

 

ja havia lido sobre esse particionamento horizontal, mas nao achei absolutamente nada mais a fundo

como funciona esse particionamento?

 

Não é tão complicado. Basicamente é separar a tabela horizontalmente, ao invés de deixar tudo em uma só, separar os registros de acordo com alguma regra. Por exemplo, você pode fazer uma estrutura assim:

 

Produtos que comecem com a letra de A à E ficam na tabela Produtos_A_E

Produtos que comecem com a letra de F à J ficam na tabela Produtos_F_J

 

... e assim vai.

 

Mas isso é só um exemplo, você tem que pensar na melhor forma de particionar isso (até porque pode haver produtos que comecem mais com A do que com K). Outro exemplo, em uma tabela de CEP, é comum separar os registros em outras tabelas pela localidade: tabela_cep_sul, tabela_cep_sudeste, tabela_cep_norte, tabela_cep_nordeste, e etc.

 

O problema do particionamento horizontal é que você vai ter que lhe dar com várias tabelas, no momento da consulta vai ter que checar a regra para ver em qual tabela deve ir e etc., deixando as consultas um pouco mais complicadas, mas resolve o problema em tabelas com enormes quantidades de registros.

 

Mas no caso de vocês, acho muito mais sensato usar um índice composto e boa, duvido muito que vocês terão problemas nas consultas utilizando os índices de maneira correta.

 

[]s

[-rafael- 1]

mas 250 mil registros, acho que nao compensa nem mexer...

 

acho q só compensa para tabelas com milhões pra cima...

[criatividade zero 17]

e pensar que eu li qur tinha que fazer varias configurações no sql pra funcionar essa tal particao H.

ficou ate facil entender

 

no exemplo do rapaz

tabela: usuarios

tabela: produtos

tabela: categoria

 

se ao mes 1000 usuarios cadastrar 100 prod. em 10 categorias, teriamos 1.000.000

poderia - de forma eficiente - agrupar em um campo texto as informações em forma de array...

 

tbl_produto

col_id_user col_nome_produto

1 carro velho, panela, radio

2 copo de plastico, telefone quebrado, chiclete mastigado, meia furada

3 um monte de coisa

 

usar os dados em forma de array para listar

col_nome_produto = col_nome_produto + novo item

deletar o item (numero) correspondente à array

 

e por ai vai

eu cheguei a testar isso em ASP um a um tempo e funcionou sem problema

se levarmos em conta o custo entre uma consulta em milhoes de registros e um loop na array, acho que é mais em conta

 

 

é +- parecido com a logica que você passou?

[mad.onion 0]

É que na verdade tem bancos que fazem o particionamento horizontal de forma automática, por isso você leu as várias configurações.

 

Se eu entendi direito a sua ideia, não, não é parecido e eu não usaria isso porque você perderia a possibilidade de relacionamentos (joins com a tabela produto), ficaria muito mais difícil pra fazer consultas, dar updates, deletes e etc, não vale a pena o ganho de desempenho.

 

Faz um índice bem bolado e boa. Se ao longo do tempo você achar que está demorando muito as consultas, aí você implementa o particionamento.

[criatividade zero 17]

não vale a pena o ganho de desempenho.

 

seria uma unica consulta à coluna do membro, e não numa tbl de milhoes de registros

o ganho é significativo, ja fiz testes em ASP e não deu nenhum problema

 

nesse seu esquema, como seria montada a tabela de produtos horizontalmente?

nao ficou claro isso pra mim

[DuuuuDuuuu 1]

é eu falei 50 usuarios pq é oq eu pretendo começa, e em produtos chutei bem baixo, pq é um aplicativo de controle, e se for por exemplo uma livraria o numero de produtos passa de 10 mil em qualquer livraria pequena.

 

eu achei aqui algo bem interresante que ajudo a agiliza a busca de produtos por categoria

 

PHP e MySQL para iniciantes – Consulta Avançada

Relacionamento de Tabelas no MySQL

 

é da chave primaria eu coloquei, esqueci de citar que iria ser assim a tabela produtos:

 

tabela: produtos

|id|categoria|nome|id_usuario|

 

e sobre esse particionamento horizontal, vi algo na internet, voce pode estipular a regra, mas num consegui entende como eu vou usar ele depois, e como vou poder continuar ussando o join para a tabela categorias

interagir com a tabela produtos, seria necessario as duas serem particionadas horizontalmente ou não prescisa?

 

achei isso na internet, bem interresante a materia

[mad.onion 0]

Colegas, o particionamento horizontal, no caso do MySQL (a menos que haja nele alguma coisa automatizada que eu não saiba) terá de ser feito a mão. As regras para separar as tabelas terão de ser boladas por vocês, pois vocês conhecem melhor como será a tabela de produtos.

 

Eu sugeri um exemplo de separar pelas letras dos nomes do produtos, pode ser feito assim também, mas convém vocês debaterem qual será o melhor jeito. O objetivo é tentar deixar as várias tabelas com tamanhos parecidos (número de linhas), isto é, lembrar que dependendo da regra, cada tabela pode ter menos ou mais dados, então tentem criar uma regra que divida bem os dados (por exemplo, se dividir pela letra inicial do nome, lembrar que é comum ter muito mais produtos que comecem com a letra M do que com a letra W. Logo, a letra W poderia ficar junto com outra(s), e assim vai...)

 

Na hora da pesquisa, você precisa escolher uma tabela de onde vai dar o select, pois os produtos estarão distribuídos em mais de uma tabela. Para escolher é só seguir a regra que vocês mesmos criaram, por exemplo, usando o exemplo que dei das letras, se eu quero dar um update no produto "Sabonete Lavanda 10 gramas", eu sei que ele começa com S e estará na tabela Produtos_S, logo, UPDATE Produtos_S SET nome = "Sabonete alterado" WHERE ProdutoID = XX.

 

Vocês também podem dividir o produto por quantidade baseado na chave primária, por exemplo, uma tabela vai conter os produtos com ID de 1 a 200 mil, a outra de 201 mil a 400 mil, e assim vai.

 

Entenderam?

[-rafael- 1]

tem um link legal sobre particionamento

 

http://dev.mysql.com/tech-resources/articles/mysql_5.1_partitions.html