Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Então alguém teria uma ideia se existe uma forma mais correta (otimizada) para está executando uma query como essa:
SELECT
pages.p_hash,
pages.p_title,
pages.p_sector,
pages.p_created,
sectors.s_hash,
sectors.s_title,
sectors.s_link,
users.u_hash,
users.u_nameFROM
pages
INNER JOIN
sectors
ON
pages.p_sector = sectors.s_hash
INNER JOIN
users
ON
pages.p_created = users.u_hash
Não que venha ao caso mas por explicação mesmo.
Entro na tabela páginas setores e usuários . Pois tenho que apresentar dados da página, o setor onde se encontra e quem foi o autor
>
12 horas atrás, Motta disse:
desempenho depende de fatores
A questão é essa o desempenho... E a tabela "pages" possui mais de 16.000 registros.
O negócio é um website de uma prefeitura ao qual estou adicionando recursos administrativos, pois não havia um recurso para saber o que já foi postado a não ser indo paginando nas postagens, e quero implementar justamente uma lista de tudo, de forma a um click acessar uma postagem, editar/excluir de forma rápida.
A arquitetura fica sendo:
Tabela "sectors" é usada para armazenar que tipo de postagem é (Saúde, educação etc...)
Tabela "pages" é usada para armazenar os post's referentes a cada tipo de postagem.
Não programo sites , mas creio que fará o site ficar pesado ou é só um relatório ("lista de tudo") ?
Como disse só uma listagem para o administrador do sistema saber tudo que já foi postado.
Na via de tal como meu prazo está apertado e como desse jeito não vi problemas de performasse deixei como está.
Funcionou deixa quieto...
Em tese sim , mas o desempenho depende de fatores , como índices , tamanho das tabelas , estatísticas atualizadas etc.
Quanto a ordem (pages,sectors e users) e o tipo do "join" ("inner") só dá para opinar conhecendo o Sistema em si.