Quanto a parte do ORM. Vejo que o problema principal é a banalização/generalização que alguns programadores fazem. Que acabam por utilizar os bancos como meros repositórios. Conseguindo fazer uma programação enxuta e delegando as obrigações corretamente - isso pra ORM, isso para o SGBD. E os ORM com que já trabalhei permitem tal mescla sem transformar tudo em um "espaguete" de informações, funções e procedimentos.
Bruno E. A. Silva. 2011/6/28 Flavio Henrique Araque Gurgel <fha...@gmail.com>: >> Informação é sempre bom, mas há limitações: > > Sem dúvidas > >>> 1) habilito consultas lentas no log (log_min_duration_statement = 1s >>> por exemplo); analiso com o PgFouine e vou otimizando pouco a pouco. >> >> Há muitas situações em que o que pesa não são as consultas lentas, mas >> consultas rápidas e freqüentes. E não é por serem (relativamente) rápidas >> que >> não precisem de um carinho nos índices de quando em vez… > > Sem dúvida! Mas um bom ponto de partida para otimizações é trabalhar > sobre as consultas lentas, que são aquelas que os usuários percebem em > um sistema. Claro que uma otimização completa precisaria olhar todas > as consultas, mas dependendo do sistema, isso pode ser excessivamente > trabalhoso/caro de se fazer. > > Então, o que proponho é um trabalho ideal. O ótimo é inimigo do bom :) > > >>> 2) dou uma olhada na pg_statio_user_indexes e vejo como está o uso dos >>> índices existentes; se algum índice composto tiver baixa taxa de uso, >>> pode estar precisando de otimização ou remoção. >> >> Outra informação interessante, mas não fala muito sobre os índices que não >> existem e precisariam existir. > > Isso está coberto pela informação anterior (consultas lentas). > >> Combinando essas duas informações dá para cobrir muito de muitos >> sistemas, mas não tudo. > > Sem sombra de dúvidas! > >>> Para sistemas em implementação, se estiver usando um ORM, dá pra catar >>> a lista de consultas pré-formatadas e trabalhar em cima delas. >> >> Se estiver usando ORM, dá para sentar na sarjeta e chorar… :-( > > Nem sempre. ORMs podem ser bem utilizados. > O que não dá é pra "entregar tudo" para o ORM, deixar que ele se vire > com todos os objetos. Um banco bem desenhado junto a um ORM bem > configurado pode facilitar a vida do DBA de produção e também do > programador. > > []s > Flavio Gurgel > _______________________________________________ > pgbr-geral mailing list > pgbr-geral@listas.postgresql.org.br > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
