Respondendo no corpo do texto. Em 17/04/08, Mozart Hasse <[EMAIL PROTECTED]> escreveu: > > Alexsander, > > > Havia um flag (...). Comparando com os SELECT's feitos à mão, na maioria > > > dos casos > > não há diferença de performance. O FW tem inclusive um modo de "debug" > que > > mostra o SQL que foi gerado. > > > Nem todo mundo pode se dar ao luxo de usar uma query mais lenta, > especialmente > se ela for feita dúzias de vezes por minuto ou se o otimizador resolver > ler > a tabela > inteira com milhões de registros. O que vocês fazem quando a consulta > precisa de > desempenho, fazem à mão? Se toda a consulta que fica lenta precisa ser > feita > à mão, > quanto sobra para fazer automaticamente?
Os comandos feitos à mão foram usados apenas para efeito de comparação. Na imensa maioria dos casos (algo em torno de 99% dos comandos executados ao longo de um dia) os códigos SQL gerados pelo Framework são exatamente idênticos aos que seriam usados se fosse preciso criá-los manualmente. Por exemplo, ao mexer num cadastro é feito um "UPDATE tabela SET coluna1=valor, coluna2=valor etc WHERE chave1 = pk1 AND chave2 = pk2 etc" que acaba sendo padronizado, mesmo fazendo à mão você vai escrever a mesma coisa. Na imensa maioria das vezes você faz SELECT's pela(s) chave(s) ou através de pesquisa em poucos campos. Nesses casos o Framework traz facilidade de uso... por exemplo, para buscar pela(s) chave(s) você pode digitar objXXX, teclar "ponto" e deixar a IDE mostrar os métodos, depois selecionar "LocateByPk". A própria IDE vai mostrar os nomes das propriedades/colunas necessárias que precisam ser passadas como parâmetro... e isso poupa tempo na programação. Quando é necessário um SELECT "diferente" pode-se usar a classe TDAOQUery que tem métodos como QueryByTemplate( ) ou QueryByFreeSQL( ), por exemplo. Essa classe tem até métodos para fazer agregações (GROUP BY), mas sempre acaba surgindo alguma necessidade que precisa ser feita à mão. Mas fazer SQL à mão é uma exceção, não a regra. > Nosso maior problema é educar o programador... por exemplo, se ele quer > > mostrar uma lista de pedidos com os nomes dos clientes, ele *NÃO* deve > > fazer > > uma query na tabela pedidos e depois varrer, dentro do FOR, mandando > > exibir > > > conteúdo de lista_pedido[i].Cliente.Nome (pois isso irá gerar um SELECT > > pra cada pedido), mas SIM fazer uma query em uma view criada > > especificamente > > para este fim. > > > Peraí, eu entendi direito? Fazer uma view por query específica do > sistema?! > Quantas > views _por tabela_ você acha aceitável e/ou produtivo? > > > Só curiosidade, Mais uma vez, a questão aqui é o volume. Mais de 95% das tabelas não têm view alguma; um punhado de tabelas, das mais utilizadas, ficaram com 5 ou 6 views cada uma, em média. Isso permite que os JOIN's mais complexos sejam feitos à mão, nas VIEW's, otimizando o desempenho. A imensa maioria do código que chega aos servidores é gerado pelo Framework. A questão é que nenhum Framework tem inteligência suficiente para fazer JOIN's complexos que apresentem um bom desempenho. Essa tarefa pode ficar para o DBA ou para o programador, por exemplo. O resto dos comandos SQL, que no fim das contas respondem por 99% dos comandos executados durante o período de um dia, são simples e podem ser perfeitamente gerados pelo Framework. Não é preciso muita inteligência para varrer um objeto e montar um INSERT com as colunas necessárias -- por exemplo, verificando as colunas que são NOT NULL, as propriedades que não estão com NULL e as colunas que têm valor DEFAULT na tabela. O Framework consegue inclusive detectar alguns problemas (como a falta de valor em uma propriedade cuja coluna é NOT NULL) antes mesmo de mandar o comando para o banco de dados. Mozart Hasse > > > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > -- Atenciosamente, Alexsander da Rosa Linux User #113925
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
