Paginação sem LIMIT
40 views
Skip to first unread message
Jean Pimentel
Apr 26, 2009, 8:18:18 PM4/26/09
to ph...@googlegroups.com
Já que todo mundo achou isso interessante e acredito que muitos tentarão fazer, porque não desenvolvermos alguma coisa coletivamente?
Será que com o WHERE conseguiremos fazer qualquer coisa sem gambiarra?
Att,
Jean Pimentel - www.jeanpimentel.com.br
Analista de Sistemas - Ato Interativo - Juiz de Fora/MG
Será que com o WHERE conseguiremos fazer qualquer coisa sem gambiarra?
Att,
Jean Pimentel - www.jeanpimentel.com.br
Analista de Sistemas - Ato Interativo - Juiz de Fora/MG
Rodrigo de Oliveira
Apr 26, 2009, 9:33:05 PM4/26/09
to ph...@googlegroups.com
desculpem quem achou o contrario, mas eu achei isso ridículo....
2009/4/26 Jean Pimentel <jea...@gmail.com>
Diego Henrique Oliveira
Apr 26, 2009, 9:46:53 PM4/26/09
to ph...@googlegroups.com
Não sei a ideia para se fazer paginação sem usar o limit, mas posso dizer uma coisa, deve ser uma tarefa muito ardua a ponto de questionar: se existe o recurso no banco de dados, porque não usar? porque perder tempo desenvolvendo uma solução complicada para algo que poderia ser simples? Aonda fica o conceito KISS (keep it simple, stupid)? E a maior pergunta na minha opinião: se o uso do limit torna o banco de dados lento, isso não seria um problema do banco de dados que os desenvolvedores deveriam corrigir?
:)
Diego Henrique
E-mail: diegoho...@yahoo.com.br
Cel: (31) 8415 4732
Website: http://www.diegoholiveira.com
From: Rodrigo de Oliveira <r.ef...@gmail.com>
To: ph...@googlegroups.com
Sent: Sunday, April 26, 2009 10:33:05 PM
Subject: [PHP MG] Re: Paginação sem LIMIT
:)
Diego Henrique
E-mail: diegoho...@yahoo.com.br
Cel: (31) 8415 4732
Website: http://www.diegoholiveira.com
From: Rodrigo de Oliveira <r.ef...@gmail.com>
To: ph...@googlegroups.com
Sent: Sunday, April 26, 2009 10:33:05 PM
Subject: [PHP MG] Re: Paginação sem LIMIT
Rodrigo de Oliveira
Apr 26, 2009, 9:54:57 PM4/26/09
to ph...@googlegroups.com
pois é. com certeza... no oracle por ex, o limit LIMITA de verdade :P
vamos ver se agora que a oracle tem o mysql na mao eles consertam isso :P
vamos ver se agora que a oracle tem o mysql na mao eles consertam isso :P
2009/4/26 Diego Henrique Oliveira <diegoho...@yahoo.com.br>
Euber (Malk)
Apr 27, 2009, 9:12:39 AM4/27/09
to PHP MG
Pelo oque entendi , teria de ser feito uma consulta antes para
determinar quantidade de registros existentes ou seja um COUNT com os
mesmas condiçoes que seria usado na segunda consulta.
Mas fica minha duvida, como poderiamos definir o limite EX: codigo >=
1 and codigo <= 10;
esse exemplo so serviria se todos os codigo fossem sequencias e nunca
pudessem ser apagados.
então WTF?
mais tem que olhar também a aplicação, se o for usar isso em uma query
com tabelas de 100 registros usa limite mesmo porque o trabalho talvez
não compense.
determinar quantidade de registros existentes ou seja um COUNT com os
mesmas condiçoes que seria usado na segunda consulta.
Mas fica minha duvida, como poderiamos definir o limite EX: codigo >=
1 and codigo <= 10;
esse exemplo so serviria se todos os codigo fossem sequencias e nunca
pudessem ser apagados.
então WTF?
mais tem que olhar também a aplicação, se o for usar isso em uma query
com tabelas de 100 registros usa limite mesmo porque o trabalho talvez
não compense.
Rodrigo de Oliveira
Apr 27, 2009, 9:16:45 AM4/27/09
to ph...@googlegroups.com
e nao é só isso...
como vc vai entregar hoje em dia um grid lixo sem opção de ordenação?
segundo ele usar order by com limit é caos!
fala sério...
como vc vai fazer ordenação, com paginção, usando where...
o cara viajou legal.
como vc vai entregar hoje em dia um grid lixo sem opção de ordenação?
segundo ele usar order by com limit é caos!
fala sério...
como vc vai fazer ordenação, com paginção, usando where...
o cara viajou legal.
2009/4/27 Euber (Malk) <eub...@hotmail.com>
Gustavo Campos
Apr 27, 2009, 9:22:21 AM4/27/09
to ph...@googlegroups.com
Eu acho (só acho) que dá pra você fazer a consulta inteira e
armazenar em memória de alguma forma, e depois acessar partes dessa
consulta independentemente, não?
Mas mesmo se der, eu ainda acho que fazer a consulta pelo próprio
MySQL usando o limit mesmo deva ser mais rápido, pura impressão. Não
assisti a palestra do amigo ai e não vi quais os argumentos dele, mas
estou cético.
--
Gustavo Campos
Sistemas de Informação - UFMG
Analista de Suporte - Telbrax LTDA
2009/4/27 Rodrigo de Oliveira <r.ef...@gmail.com>:
armazenar em memória de alguma forma, e depois acessar partes dessa
consulta independentemente, não?
Mas mesmo se der, eu ainda acho que fazer a consulta pelo próprio
MySQL usando o limit mesmo deva ser mais rápido, pura impressão. Não
assisti a palestra do amigo ai e não vi quais os argumentos dele, mas
estou cético.
--
Gustavo Campos
Sistemas de Informação - UFMG
Analista de Suporte - Telbrax LTDA
2009/4/27 Rodrigo de Oliveira <r.ef...@gmail.com>:
Michael Mafort
Apr 27, 2009, 9:25:31 AM4/27/09
to ph...@googlegroups.com
Talvez essa gambiarra fosse útil para um servidor 286, como trabalhamos com mais memória e processamento, o que ele diz acho completamente irrelevante.
Acho que ele deveria ter dito o seguinte, uma consulta com 10 resultados que foi filtrada por condições exige menos processamento do que uma que retorna 10 resultados onde tinham 10000 e que foi limitada com o uso de limit.
--
Michael Mafort | Diretor de Tecnologia
CRIASOL - Desenvolvimento Web
www.criasol.com.br
+55 31 9846-5904
michae...@criasol.com.br
Acho que ele deveria ter dito o seguinte, uma consulta com 10 resultados que foi filtrada por condições exige menos processamento do que uma que retorna 10 resultados onde tinham 10000 e que foi limitada com o uso de limit.
2009/4/27 Gustavo Campos <guhc...@gmail.com>
--
Michael Mafort | Diretor de Tecnologia
CRIASOL - Desenvolvimento Web
www.criasol.com.br
+55 31 9846-5904
michae...@criasol.com.br
Rodrigo de Oliveira
Apr 27, 2009, 9:26:03 AM4/27/09
to ph...@googlegroups.com
com certeza é mais rápido... carregar na memória sim seria um caos... e tambem o que ele alegou foi fazer com where, nao pode trazer tudo.
pra fazer um teste e comprovar que é mais rápido (nao o limit e o where, usar ou nao o limit) é só pegar uma tabela com 500 mil registros e fazer:
select * from tabela
e depois fazer:
select * from tabela limit 1,5
pra fazer um teste e comprovar que é mais rápido (nao o limit e o where, usar ou nao o limit) é só pegar uma tabela com 500 mil registros e fazer:
select * from tabela
e depois fazer:
select * from tabela limit 1,5
2009/4/27 Gustavo Campos <guhc...@gmail.com>
Rafael Matos
Apr 27, 2009, 9:31:44 AM4/27/09
to ph...@googlegroups.com
Eu não vi a palestra, então não sei o que foi falado, mas acho que vale a pena vocês darem uma olhada aqui:
http://dev.mysql.com/doc/refman/4.1/en/limit-optimization.html
e aqui:
http://www.mysqlperformanceblog.com/2006/09/01/order-by-limit-performance-optimization/
Se depois ainda quiserem fazer paginação com where....
http://dev.mysql.com/doc/refman/4.1/en/limit-optimization.html
e aqui:
http://www.mysqlperformanceblog.com/2006/09/01/order-by-limit-performance-optimization/
Se depois ainda quiserem fazer paginação com where....
Gustavo Campos
Apr 27, 2009, 9:33:06 AM4/27/09
to ph...@googlegroups.com
entendi...
De fato um tempinho de processamento é gasto pra 'filtrar' os
resultados. Mas mesmo assim eu não me convenceria sem fazer os devidos
testes que é mais rápido filtrar com um where qualquer.
o select * é mais rápido pq retorna tudo, sem filtros. O limit filtra
os resultados e retorna um subset deles, o where faz EXATAMENTE isso.
O banco precisa varrer toda a tabela e fazer as comparações das
cláusulas do WHERE, o que pra mim pode ser muito mais custoso (digamos
que envolva comparações entre strings) do que simplesmente selecionar
alguns nodos de uma lista encadeada (que se não me engano é como o
mysql deve tratar o result set em memória).
Mais uma vez, eu não sei como o MySQL implementa essas consultas, só
tenho uma vaga noção, baseada no que eu já estudei de teoria de banco
de dados, de como eles provavelmente implementaram.
De qualquer forma, mesmo que de fato exista um ganho, eu duvido (mas
posso ser convencido =D) que este seria significativo o suficiente pra
se desenvolver uma solução mais complexa em termos de código e
provavelmente desempenho: pense em quantos ciclos de CPU se precisa
pra executar um código nativo da máquina no MySQL e quantos se precisa
pra executar um código interpretado, como o do PHP.
Por mim, ficon o LIMIT mesmo, por enquanto.
De fato um tempinho de processamento é gasto pra 'filtrar' os
resultados. Mas mesmo assim eu não me convenceria sem fazer os devidos
testes que é mais rápido filtrar com um where qualquer.
o select * é mais rápido pq retorna tudo, sem filtros. O limit filtra
os resultados e retorna um subset deles, o where faz EXATAMENTE isso.
O banco precisa varrer toda a tabela e fazer as comparações das
cláusulas do WHERE, o que pra mim pode ser muito mais custoso (digamos
que envolva comparações entre strings) do que simplesmente selecionar
alguns nodos de uma lista encadeada (que se não me engano é como o
mysql deve tratar o result set em memória).
Mais uma vez, eu não sei como o MySQL implementa essas consultas, só
tenho uma vaga noção, baseada no que eu já estudei de teoria de banco
de dados, de como eles provavelmente implementaram.
De qualquer forma, mesmo que de fato exista um ganho, eu duvido (mas
posso ser convencido =D) que este seria significativo o suficiente pra
se desenvolver uma solução mais complexa em termos de código e
provavelmente desempenho: pense em quantos ciclos de CPU se precisa
pra executar um código nativo da máquina no MySQL e quantos se precisa
pra executar um código interpretado, como o do PHP.
Por mim, ficon o LIMIT mesmo, por enquanto.
Arthur Vinicius
Apr 27, 2009, 9:44:46 AM4/27/09
to ph...@googlegroups.com
O que foi falado na palestra é que o LIMIT na verdade ele não limita a busca, ele somente retorna com o limite, mas faz a busca em todo o banco. Ou seja, ele tem um peso enorme, porque varre todo o banco do mesmo jeito.
Pelo que eu entendi você teria que ter campo para controle, um campo com uma data, um inteiro, sei lá como p/ controlar a sua paginação.
2009/4/27 Rafael Matos <rafaeld...@gmail.com>
Rodrigo de Oliveira
Apr 27, 2009, 9:47:06 AM4/27/09
to ph...@googlegroups.com
pois é, mas se precisar ordenar... bye bye esse campo! :P
2009/4/27 Arthur Vinicius <arthu...@gmail.com>
Michael Mafort
Apr 27, 2009, 9:47:25 AM4/27/09
to ph...@googlegroups.com
Mas ai ta o where também varre o banco todo e o pior ele não retorna nada até que seja lido todo o banco, já o limit retorna o resultado limitado e em background continua a consulta.
2009/4/27 Arthur Vinicius <arthu...@gmail.com>
Arthur Vinicius
Apr 27, 2009, 9:48:45 AM4/27/09
to ph...@googlegroups.com
hahahaha, entramos em loop infinito. Cade o cara do mysql para explicar?
2009/4/27 Michael Mafort <michae...@gmail.com>
Gustavo Campos
Apr 27, 2009, 9:52:53 AM4/27/09
to ph...@googlegroups.com
Recomendo ler os links que o Rafael mandou, dei uma olhada rápida e deu pra notar algumas das coisas que provavelmente o palestrante falou.
--
Gustavo Campos
Sistemas de Informação - UFMG
Analista de Suporte - Telbrax LTDA
--
Gustavo Campos
Sistemas de Informação - UFMG
Analista de Suporte - Telbrax LTDA
2009/4/27 Arthur Vinicius <arthu...@gmail.com>
Marcone Gledson de Almeida
Apr 27, 2009, 10:01:45 AM4/27/09
to ph...@googlegroups.com
Hummm ...
Gustavo, segundo a palestra do Wagner Bianchi da MySQL no 1EPHPMG,
justamente o LIMIT não trata os resultados como um intervalo, é preciso
ele buscar toda a tabela e trazer os registros que foram especificados
no LIMIT. A claúsula que pesquisa por intervalos é o WHERE. Agora o que
você falou sobre a pesquisa de WHERE com strings realmente é custoso. A
paginação por WHERE só se justifica se for pelos indices das tabelas.
Agora por um outro lado é notório que muitos desenvolvedores já
incorporam o LIMIT em suas aplicações (inclusive eu). Eu acredito que
esta mudança que LIMIT para WHERE só se justifica quando o sistema é de
médio a grande porte e necessite de melhor desempenho.
Att,
Marcone Gledson de Almeida
(31) 9836-8408
Gustavo Campos escreveu:
Gustavo, segundo a palestra do Wagner Bianchi da MySQL no 1EPHPMG,
justamente o LIMIT não trata os resultados como um intervalo, é preciso
ele buscar toda a tabela e trazer os registros que foram especificados
no LIMIT. A claúsula que pesquisa por intervalos é o WHERE. Agora o que
você falou sobre a pesquisa de WHERE com strings realmente é custoso. A
paginação por WHERE só se justifica se for pelos indices das tabelas.
Agora por um outro lado é notório que muitos desenvolvedores já
incorporam o LIMIT em suas aplicações (inclusive eu). Eu acredito que
esta mudança que LIMIT para WHERE só se justifica quando o sistema é de
médio a grande porte e necessite de melhor desempenho.
Att,
Marcone Gledson de Almeida
(31) 9836-8408
Gustavo Campos escreveu:
Gustavo Campos
Apr 27, 2009, 10:01:23 AM4/27/09
to ph...@googlegroups.com
Marcone
Nos links que o Rafael mandou, incluindo o site do próprio MySQL, há
informações sobre várias situações onde o MySQL de fato *não faz* full
table scan usando LIMIT.
recomendo mais uma vez a leitura pra todo mundo.
Nos links que o Rafael mandou, incluindo o site do próprio MySQL, há
informações sobre várias situações onde o MySQL de fato *não faz* full
table scan usando LIMIT.
recomendo mais uma vez a leitura pra todo mundo.
--
Gustavo Campos
Sistemas de Informação - UFMG
Analista de Suporte - Telbrax LTDA
2009/4/27 Marcone Gledson de Almeida <marco...@gmail.com>:
Gustavo Campos
Sistemas de Informação - UFMG
Analista de Suporte - Telbrax LTDA
messala
Apr 28, 2009, 11:07:37 AM4/28/09
to PHP MG
Foi exatamente essa pergunta que eu fiz lá na palestra, mas pareceu
que ele não entendeu direito (acho que me expressei mal), tanto que
ele disse aquilo sobre ORDER BY + LIMIT = caos! Eu estava perguntando
exatamente isso: se eu vou usar um WHERE pra limitar a consulta, como
eu vou ordernar tudo antes de usar o WHERE. Mas tudo bem.
Acho que o maior problema ali, é que o palestrante deva ter esquecido
que ministrava para profissionais (ou aspirantes a profissionais) que
dificilmente irá trabalhar constantemente com uma tabela de 1000000000
de linhas, a ponto de uma paginação (incluindo ordenação por ORDER BY)
se tornar um caos. O
On 27 abr, 10:47, Rodrigo de Oliveira <r.efr...@gmail.com> wrote:
> pois é, mas se precisar ordenar... bye bye esse campo! :P
>
> 2009/4/27 Arthur Vinicius <arthurn...@gmail.com>
>
> >> Se depois ainda quiserem fazer paginação com where.... [?]
>
> >> 2009/4/27 Rodrigo de Oliveira <r.efr...@gmail.com>
>
>
>
> 344.gif
> < 1KVisualizarFazer download
que ele não entendeu direito (acho que me expressei mal), tanto que
ele disse aquilo sobre ORDER BY + LIMIT = caos! Eu estava perguntando
exatamente isso: se eu vou usar um WHERE pra limitar a consulta, como
eu vou ordernar tudo antes de usar o WHERE. Mas tudo bem.
Acho que o maior problema ali, é que o palestrante deva ter esquecido
que ministrava para profissionais (ou aspirantes a profissionais) que
dificilmente irá trabalhar constantemente com uma tabela de 1000000000
de linhas, a ponto de uma paginação (incluindo ordenação por ORDER BY)
se tornar um caos. O
On 27 abr, 10:47, Rodrigo de Oliveira <r.efr...@gmail.com> wrote:
> pois é, mas se precisar ordenar... bye bye esse campo! :P
>
>
> > O que foi falado na palestra é que o LIMIT na verdade ele não limita a
> > busca, ele somente retorna com o limite, mas faz a busca em todo o banco. Ou
> > seja, ele tem um peso enorme, porque varre todo o banco do mesmo jeito.
>
> > Pelo que eu entendi você teria que ter campo para controle, um campo com
> > uma data, um inteiro, sei lá como p/ controlar a sua paginação.
>
> > 2009/4/27 Rafael Matos <rafaeldvinc...@gmail.com>
> > O que foi falado na palestra é que o LIMIT na verdade ele não limita a
> > busca, ele somente retorna com o limite, mas faz a busca em todo o banco. Ou
> > seja, ele tem um peso enorme, porque varre todo o banco do mesmo jeito.
>
> > Pelo que eu entendi você teria que ter campo para controle, um campo com
> > uma data, um inteiro, sei lá como p/ controlar a sua paginação.
>
>
> > Eu não vi a palestra, então não sei o que foi falado, mas acho que vale a
> >> pena vocês darem uma olhada aqui:
>
> >>http://dev.mysql.com/doc/refman/4.1/en/limit-optimization.html
>
> >> e aqui:
>
> >>http://www.mysqlperformanceblog.com/2006/09/01/order-by-limit-perform...
> > Eu não vi a palestra, então não sei o que foi falado, mas acho que vale a
> >> pena vocês darem uma olhada aqui:
>
> >>http://dev.mysql.com/doc/refman/4.1/en/limit-optimization.html
>
> >> e aqui:
>
>
> >> Se depois ainda quiserem fazer paginação com where.... [?]
>
> >> 2009/4/27 Rodrigo de Oliveira <r.efr...@gmail.com>
>
> >>> com certeza é mais rápido... carregar na memória sim seria um caos... e
> >>> tambem o que ele alegou foi fazer com where, nao pode trazer tudo.
>
> >>> pra fazer um teste e comprovar que é mais rápido (nao o limit e o where,
> >>> usar ou nao o limit) é só pegar uma tabela com 500 mil registros e fazer:
>
> >>> select * from tabela
>
> >>> e depois fazer:
>
> >>> select * from tabela limit 1,5
>
> >>> 2009/4/27 Gustavo Campos <guhcam...@gmail.com>
> >>> com certeza é mais rápido... carregar na memória sim seria um caos... e
> >>> tambem o que ele alegou foi fazer com where, nao pode trazer tudo.
>
> >>> pra fazer um teste e comprovar que é mais rápido (nao o limit e o where,
> >>> usar ou nao o limit) é só pegar uma tabela com 500 mil registros e fazer:
>
> >>> select * from tabela
>
> >>> e depois fazer:
>
> >>> select * from tabela limit 1,5
>
>
> >>>> Eu acho (só acho) que dá pra você fazer a consulta inteira e
> >>>> armazenar em memória de alguma forma, e depois acessar partes dessa
> >>>> consulta independentemente, não?
>
> >>>> Mas mesmo se der, eu ainda acho que fazer a consulta pelo próprio
> >>>> MySQL usando o limit mesmo deva ser mais rápido, pura impressão. Não
> >>>> assisti a palestra do amigo ai e não vi quais os argumentos dele, mas
> >>>> estou cético.
>
> >>>> --
> >>>> Gustavo Campos
> >>>> Sistemas de Informação - UFMG
> >>>> Analista de Suporte - Telbrax LTDA
>
> >>>> 2009/4/27 Rodrigo de Oliveira <r.efr...@gmail.com>:
> >>>> Eu acho (só acho) que dá pra você fazer a consulta inteira e
> >>>> armazenar em memória de alguma forma, e depois acessar partes dessa
> >>>> consulta independentemente, não?
>
> >>>> Mas mesmo se der, eu ainda acho que fazer a consulta pelo próprio
> >>>> MySQL usando o limit mesmo deva ser mais rápido, pura impressão. Não
> >>>> assisti a palestra do amigo ai e não vi quais os argumentos dele, mas
> >>>> estou cético.
>
> >>>> --
> >>>> Gustavo Campos
> >>>> Sistemas de Informação - UFMG
> >>>> Analista de Suporte - Telbrax LTDA
>
> >>>> > e nao é só isso...
>
> >>>> > como vc vai entregar hoje em dia um grid lixo sem opção de ordenação?
> >>>> > segundo ele usar order by com limit é caos!
>
> >>>> > fala sério...
>
> >>>> > como vc vai fazer ordenação, com paginção, usando where...
>
> >>>> > o cara viajou legal.
>
> >>>> > 2009/4/27 Euber (Malk) <eub...@hotmail.com>
>
> >>>> >> Pelo oque entendi , teria de ser feito uma consulta antes para
> >>>> >> determinar quantidade de registros existentes ou seja um COUNT com os
> >>>> >> mesmas condiçoes que seria usado na segunda consulta.
>
> >>>> >> Mas fica minha duvida, como poderiamos definir o limite EX: codigo
> >>>> >=
> >>>> >> 1 and codigo <= 10;
> >>>> >> esse exemplo so serviria se todos os codigo fossem sequencias e nunca
> >>>> >> pudessem ser apagados.
>
> >>>> >> então WTF?
>
> >>>> >> mais tem que olhar também a aplicação, se o for usar isso em uma
> >>>> query
> >>>> >> com tabelas de 100 registros usa limite mesmo porque o trabalho
> >>>> talvez
> >>>> >> não compense.
>
> > --
> > Arthur Vinicius
> > arthurn...@gmail.com | arthurvinicius.com
>
> >>>> > como vc vai entregar hoje em dia um grid lixo sem opção de ordenação?
> >>>> > segundo ele usar order by com limit é caos!
>
> >>>> > fala sério...
>
> >>>> > como vc vai fazer ordenação, com paginção, usando where...
>
> >>>> > o cara viajou legal.
>
> >>>> > 2009/4/27 Euber (Malk) <eub...@hotmail.com>
>
> >>>> >> Pelo oque entendi , teria de ser feito uma consulta antes para
> >>>> >> determinar quantidade de registros existentes ou seja um COUNT com os
> >>>> >> mesmas condiçoes que seria usado na segunda consulta.
>
> >>>> >> Mas fica minha duvida, como poderiamos definir o limite EX: codigo
> >>>> >=
> >>>> >> 1 and codigo <= 10;
> >>>> >> esse exemplo so serviria se todos os codigo fossem sequencias e nunca
> >>>> >> pudessem ser apagados.
>
> >>>> >> então WTF?
>
> >>>> >> mais tem que olhar também a aplicação, se o for usar isso em uma
> >>>> query
> >>>> >> com tabelas de 100 registros usa limite mesmo porque o trabalho
> >>>> talvez
> >>>> >> não compense.
>
> > --
> > Arthur Vinicius
>
>
>
> 344.gif
> < 1KVisualizarFazer download
messala
Apr 28, 2009, 11:10:58 AM4/28/09
to PHP MG
O que ele disse, se for realmente como ele disse, faz sentido. Mas de
modo algum mostra que devemos rever nossas querys, mas sim que o MySQL
tá dando pra trás nesse quesito. Senão, pra que diabos serviria essa
budega de LIMIT então?
modo algum mostra que devemos rever nossas querys, mas sim que o MySQL
tá dando pra trás nesse quesito. Senão, pra que diabos serviria essa
budega de LIMIT então?
Pablo Leal
Apr 29, 2009, 7:40:12 AM4/29/09
to PHP MG
Galera o negocio é o seguinte.
tudo o que essa lista sabe sobre busca no Mysql está errado.
o negocio é sempre cadastrar já na ordem, com campo sequencial,nunca
excluir nada e de preferencia banco comm menos de 1000 registros. Se
aparecer algo a ser inserido que esteja fora da ordem deve fazer uma
nova aplicação para não causar o caos na primeira. rsrsrsrsrsrsrsrsrs
O bacana é que nós deixou com uma pulga atraz da orelha e estamos
crescendo com isso.
Mas concordo com o Arthur, " entramos em loop infinito. Cade o cara do
mysql para explicar?".
O cara só falou que azul é feio mas não falou qual é a cor bonita.
tudo o que essa lista sabe sobre busca no Mysql está errado.
o negocio é sempre cadastrar já na ordem, com campo sequencial,nunca
excluir nada e de preferencia banco comm menos de 1000 registros. Se
aparecer algo a ser inserido que esteja fora da ordem deve fazer uma
nova aplicação para não causar o caos na primeira. rsrsrsrsrsrsrsrsrs
O bacana é que nós deixou com uma pulga atraz da orelha e estamos
crescendo com isso.
Mas concordo com o Arthur, " entramos em loop infinito. Cade o cara do
mysql para explicar?".
O cara só falou que azul é feio mas não falou qual é a cor bonita.
Sandro J. S. Souza
Apr 29, 2009, 7:42:49 AM4/29/09
to ph...@googlegroups.com
Interessante:
http://forge.mysql.com/wiki/Top10SQLPerformanceTips
--
Atenciosamente,
Sandro J. S. Souza
www.sandro.eti.br
http://forge.mysql.com/wiki/Top10SQLPerformanceTips
--
Atenciosamente,
Sandro J. S. Souza
www.sandro.eti.br
rondine...@hotmail.com
May 6, 2009, 10:34:23 AM5/6/09
to PHP MG
é verdade Pablo... concordo com vc.
bom eu entendi que isso se aplica somente em alguns casos,
que dependendo da situaçao creio que seja interessante, mais se a
mysql sabe deste bug,
porque nao melhorar isso ?
bom eu entendi que isso se aplica somente em alguns casos,
que dependendo da situaçao creio que seja interessante, mais se a
mysql sabe deste bug,
porque nao melhorar isso ?
Diego Henrique Oliveira
May 6, 2009, 10:44:34 AM5/6/09
to ph...@googlegroups.com
Sobre isso, achei essa apresentação bem interessante:
http://www.percona.com/ppc2009/PPC2009_mysql_pagination.pdf
Abraços
http://www.percona.com/ppc2009/PPC2009_mysql_pagination.pdf
Abraços
Diego Henrique
E-mail: diegoho...@yahoo.com.br
Cel: (31) 8415 4732
Website: http://www.diegoholiveira.com
From: "rondine...@hotmail.com" <rondine...@hotmail.com>
To: PHP MG <ph...@googlegroups.com>
Sent: Wednesday, May 6, 2009 11:34:23 AM
Subject: [PHP MG] Re: Paginação sem LIMIT
Lucas Arruda
May 6, 2009, 11:50:10 AM5/6/09
to ph...@googlegroups.com
é verdade Pablo... concordo com vc.
bom eu entendi que isso se aplica somente em alguns casos,
que dependendo da situaçao creio que seja interessante, mais se a
mysql sabe deste bug,
porque nao melhorar isso ?
esta fazendo um simples blog ou site pessoal, vale a pena fazer um SQL um pouco
mais bem feito, sem abusar nas consultas ou gerar consultas excessivas, e guardar
Josimar
May 6, 2009, 2:40:58 PM5/6/09
to ph...@googlegroups.com
Concordo plenamente...
Trabalho com PHP e MySQL a 4 anos.
Já desenvolvi um jogo de tabuleiro (batalha naval) com a plataforma no projeto para faculdade para mostrar que as linguagens e os bancos podem ser utilizados para qualquer coisa.
Mas me deparei com um grande problema nas consultas que o jogo fazia com o banco.
Tive de reaprender praticamente a usar o Mysql.
Depois apliquei as ideias nos sistemas que desenvolvi daí em diante e percebi uma melhora considerável de performance.
Até
-----------------------------------
Josimar Jaime Finamore
Análise e Desenvolvimento de Soluções
TEL.: (31) 87095932
MSN: josimar...@gmail.com
SKIPE: espacodovale
http://josimarfinamore.6te.net
** Procurando HOSPEDAGEM?
Escolha seu plano de hospedagem na KINGHOST. Copie o link abaixo e cole no seu navegador e ganhe desconto.
http://www.kinghost.com.br/promo/TK5HKRPAR4SFR.html
Trabalho com PHP e MySQL a 4 anos.
Já desenvolvi um jogo de tabuleiro (batalha naval) com a plataforma no projeto para faculdade para mostrar que as linguagens e os bancos podem ser utilizados para qualquer coisa.
Mas me deparei com um grande problema nas consultas que o jogo fazia com o banco.
Tive de reaprender praticamente a usar o Mysql.
Depois apliquei as ideias nos sistemas que desenvolvi daí em diante e percebi uma melhora considerável de performance.
Até
-----------------------------------
Josimar Jaime Finamore
Análise e Desenvolvimento de Soluções
TEL.: (31) 87095932
MSN: josimar...@gmail.com
SKIPE: espacodovale
http://josimarfinamore.6te.net
** Procurando HOSPEDAGEM?
Escolha seu plano de hospedagem na KINGHOST. Copie o link abaixo e cole no seu navegador e ganhe desconto.
http://www.kinghost.com.br/promo/TK5HKRPAR4SFR.html
2009/5/6 Lucas Arruda <lucas...@gmail.com>
Reply all
Reply to author
Forward
0 new messages