[pgbr-geral] Sistema de arquivos
Pessoal, qual o sistema de arquivos recomendado para o banco de dados postgresql: Xfs ou Ext4. Pretendo usar SSD, e parece que somente o Ext4 tem suporte a TRIM (necessario no SSD). Jean Domingues.___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Sistema de arquivos
2012/9/11 Jean Domingues ejdom...@yahoo.com.br: qual o sistema de arquivos recomendado para o banco de dados postgresql: Xfs ou Ext4. Ambos são recomendados. Eu, particularmente, aprecio no ext4 que ele aproveita os utilitários dos ext anteriores (2 e 3), facilitando para o pobre ignorante aqui que nunca lidou com XFS e nem tem idéia do ferramental disponível para ele… Pretendo usar SSD, e parece que somente o Ext4 tem suporte a TRIM (necessario no SSD). Então tua decisão já está tomada? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Select registros maiores que uma data
2012/9/11 Nelson Luiz Gonzaga ngonz...@ig.com.br: Isto é, pego a data de aprovacao e listo os registros com data maiores. WHERE alteração aprovação Imagino que não seja isso, mas impossível dizer sem mais informações. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Select registros maiores que uma data
Em terça-feira, 11 de setembro de 2012 14:32:30, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/9/11 Nelson Luiz Gonzaga ngonz...@ig.com.br: Isto é, pego a data de aprovacao e listo os registros com data maiores. WHERE alteração aprovação Imagino que não seja isso, mas impossível dizer sem mais informações. Digo mais, seria legal de sua parte fazer um esboço do que queres utilizando a SQL e mandar no email. Uma tentativa de montar a query. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Substituição dos ORM
Senhores, Na experiência de vocês junto aos programadores, como tem sido para eliminar ou substituir os softwares ORM? Ou não tem sido feito por n motivos? Estou imaginando uma arquitetura de software que pode substituir o famigerado ORM em meus sistemas, nada inovador somente aplicação de padrões de desenvolvimento. E queria saber como tem sido a experiência nesta questão por parte de vocês. Abraços, Flávio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Qual a linguagem e ORM usados? Abraços, Eduardo Alexandre Em 11 de setembro de 2012 14:41, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Senhores, Na experiência de vocês junto aos programadores, como tem sido para eliminar ou substituir os softwares ORM? Ou não tem sido feito por n motivos? Estou imaginando uma arquitetura de software que pode substituir o famigerado ORM em meus sistemas, nada inovador somente aplicação de padrões de desenvolvimento. E queria saber como tem sido a experiência nesta questão por parte de vocês. Abraços, Flávio ___ 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
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Flávio Alves Granato flavio.gran...@gmail.com: Na experiência de vocês junto aos programadores, como tem sido para eliminar ou substituir os softwares ORM? Ou não tem sido feito por n motivos? n motivos, onde n = preguiça de pensar. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11/09/2012 14:46, Eduardo Alexandre escreveu: Qual a linguagem e ORM usados? Não, não... é mais um esforço de concientização para as mudanças, por onde os senhores começam ou simplesmente tentam contornar o uso de ORM nas aplicações. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11/09/2012 14:47, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/9/11 Flávio Alves Granato flavio.gran...@gmail.com: Na experiência de vocês junto aos programadores, como tem sido para eliminar ou substituir os softwares ORM? Ou não tem sido feito por n motivos? n motivos, onde n = preguiça de pensar. poiseh, esperava que a variável n fosse preenchidos com motivos ditos nas respostas. digamos que, para ser mais enfático, n == preguiça ou mesmo não saber por onde começar. Porque os efeitos de mudanças podem ter vários tipos de reações... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Olá, Minha área primária é em desenvolvimento. Atualmente em PHP (principalmente com PHP e acesso a dados por PDO, em segundo usando o CodeIgniter com ORM) e com C# ASP.Net com e sem uso de ORM. Acho que toda tecnologia pode ser boa ou ruim. Inclusive o ORM que, se usado corretamente, não vejo consequências tão graves. Abraços, Eduardo Alexandre Em 11 de setembro de 2012 14:48, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Em 11/09/2012 14:46, Eduardo Alexandre escreveu: Qual a linguagem e ORM usados? Não, não... é mais um esforço de concientização para as mudanças, por onde os senhores começam ou simplesmente tentam contornar o uso de ORM nas aplicações. ___ 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
Re: [pgbr-geral] Select registros maiores que uma data
2012/9/11 Nelson Luiz Gonzaga ngonz...@ig.com.br: select dsc_historico,dat_ctr_inclusao from cartao_historico where id_cartao = 983421 order by dat_ctr_inclusao Documento FEITO por: RICARDO F.;2011-06-27 09:54:00.171744-03 Documento VERIFICADO por: JULIO C.;2011-06-28 15:07:48.320883-03 Documento APROVADO por: ROBERTO S.;2011-06-30 11:13:21.434396-03 Documento Aberto (somente leitura) por: LEIDIANA G.;2012-08-28 14:24:25.446029-03 Documento Formato Recarregado por: LETICIA G.;2012-09-04 11:00:49.955472-03 Documento Aberto (para edição) por: LETICIA G.;2012-09-04 11:00:54.673675-03 Documento Salvo por: LETICIA G.;2012-09-04 11:13:32.855464-03 Documento Aberto (somente leitura) por: LETICIA G.;2012-09-04 11:14:02.858886-03 Notem que na 4 linha a Leidiana acessou apenas para leitura, o que esta certo. Porem (ai a falha) apos a Leticia recarregar o formato, ela acessou para edicao e salvou o documento. Preciso listas todas as falhas que ocorreram, acessar para edicao apos aprovado. Faça um autorreferenciamento… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Flávio Alves Granato flavio.gran...@gmail.com: poiseh, esperava que a variável n fosse preenchidos com motivos ditos nas respostas. Por exemplo, uns javeiros que não queriam lidar com chaves compostas. Geralmente, também não querem aprender o modelo relacional. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11/09/2012 14:55, Eduardo Alexandre escreveu: Olá, Minha área primária é em desenvolvimento. Atualmente em PHP (principalmente com PHP e acesso a dados por PDO, em segundo usando o CodeIgniter com ORM) e com C# ASP.Net com e sem uso de ORM. Acho que toda tecnologia pode ser boa ou ruim. Inclusive o ORM que, se usado corretamente, não vejo consequências tão graves. Bem, vou pelo pensamento mais conservador. Se pode dar consequência então é de se pensar, pois pode dar consequência média e baixa pode dar problema a médio e longo prazo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11/09/2012 15:11, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/9/11 Flávio Alves Granato flavio.gran...@gmail.com: poiseh, esperava que a variável n fosse preenchidos com motivos ditos nas respostas. Por exemplo, uns javeiros que não queriam lidar com chaves compostas. Geralmente, também não querem aprender o modelo relacional. Javeiros são um problema de forma geral, normalmente programam de forma estruturada em uma linguagem orientada a objeto... sou javeiro e o mais difícil é dizer a um que ele não esta fazendo da forma correta... imagina então tirar a facilidade do Hibernate, vixi ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11 de setembro de 2012 15:20, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Bem, vou pelo pensamento mais conservador. Se pode dar consequência então é de se pensar, pois pode dar consequência média e baixa pode dar problema a médio e longo prazo. Dois pontos: O desenvolvimento precisa atender a determinados níveis de qualidade e velocidade de desenvolvimento. Se houver desenvolvedores na lista, sabem o que é receber um pedido de um recurso mirabolante pra ontem e ser obrigado a cumprir esse prazo. Geralmente esse fato se repete dia após dia, sendo tudo urgente e pra ontem. Se eu for pensar no cenário ideal, diria que é melhor fazer o software na unha, otimizado para a melhor performance possível. Mas será que isso é possível? :) Se não formos utilizar a tecnologia que pode ter consequência negativa, qual usaremos? Abraços, Eduardo Alexandre ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Select registros maiores que uma data
Em 11 de setembro de 2012 15:10, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/11 Nelson Luiz Gonzaga ngonz...@ig.com.br: select dsc_historico,dat_ctr_inclusao from cartao_historico where id_cartao = 983421 order by dat_ctr_inclusao Documento FEITO por: RICARDO F.;2011-06-27 09:54:00.171744-03 Documento VERIFICADO por: JULIO C.;2011-06-28 15:07:48.320883-03 Documento APROVADO por: ROBERTO S.;2011-06-30 11:13:21.434396-03 Documento Aberto (somente leitura) por: LEIDIANA G.;2012-08-28 14:24:25.446029-03 Documento Formato Recarregado por: LETICIA G.;2012-09-04 11:00:49.955472-03 Documento Aberto (para edição) por: LETICIA G.;2012-09-04 11:00:54.673675-03 Documento Salvo por: LETICIA G.;2012-09-04 11:13:32.855464-03 Documento Aberto (somente leitura) por: LETICIA G.;2012-09-04 11:14:02.858886-03 Notem que na 4 linha a Leidiana acessou apenas para leitura, o que esta certo. Porem (ai a falha) apos a Leticia recarregar o formato, ela acessou para edicao e salvou o documento. Preciso listas todas as falhas que ocorreram, acessar para edicao apos aprovado. Faça um autorreferenciamento… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Eu estou tentando é isso mesmo, utilizando sub-consultas da propria tabela dentro da where, mas nao consegui fazer ainda nao. Vou continuar apanhando aqui e daqui a pouco dou um K.O. neste select famigerado. Fui, Nelson ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11/09/2012 15:26, Eduardo Alexandre escreveu: Em 11 de setembro de 2012 15:20, Flávio Alves Granato flavio.gran...@gmail.com mailto:flavio.gran...@gmail.com escreveu: Bem, vou pelo pensamento mais conservador. Se pode dar consequência então é de se pensar, pois pode dar consequência média e baixa pode dar problema a médio e longo prazo. Veja bem, a questão não é com você. A culpa é de todos nós, pois também sou desenvolvedor. Dois pontos: O desenvolvimento precisa atender a determinados níveis de qualidade e velocidade de desenvolvimento. Se houver desenvolvedores na lista, sabem o que é receber um pedido de um recurso mirabolante pra ontem e ser obrigado a cumprir esse prazo. Geralmente esse fato se repete dia após dia, sendo tudo urgente e pra ontem. devemos assumir nossa grande parcela de culpa neste ponto aqui. Se eu for pensar no cenário ideal, diria que é melhor fazer o software na unha, otimizado para a melhor performance possível. Mas será que isso é possível? :) Em projetos bucha não é. O mais certo é, depende. Pois se você conseguir utilizar os argumentos corretos você consegue o que quiser. No projeto que estou o senhor que arquitetou o sistema, utilizar um ORM ( ibatis ) para ficar chamando procedures no banco, que por sorte foi imposto postgresql, mas ele queria um melhor... já sabemos qual... Se não formos utilizar a tecnologia que pode ter consequência negativa, qual usaremos? Devemos é mitigar os riscos, principalmente no momento de escolher as ferramentas, participei de um projeto em que era feito uma atualização quase inteira da base de dados pois era um momento de importação de atualização de dados em cada cliente do sistema... um tal de CASCADE ALL + FECHT EAGER nos matou de dor de cabeça, pois a base era relacional e nos objetos um continha o outro e assim por diante... e no momento de atualizar tudo ficava em loop... solução, o velho e bom SQL puro... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Eduardo Alexandre eduardog...@gmail.com: O desenvolvimento precisa atender a determinados níveis de qualidade Esse é o problema! Há pouquíssimos ORM que tenham um mínimo de qualidade. Lembro do SQL Alchemy, do Python, e acho que o Diogo havia me dito que o Rails estava com um decente opcional na versão três. velocidade de desenvolvimento. Se houver desenvolvedores na lista, sabem o que é receber um pedido de um recurso mirabolante pra ontem e ser obrigado a cumprir esse prazo. Geralmente esse fato se repete dia após dia, sendo tudo urgente e pra ontem. Mas os ORMs geralmente atrasam o resultado, introduzindo problemas. Se eu for pensar no cenário ideal, diria que é melhor fazer o software na unha, otimizado para a melhor performance possível. Mas será que isso é possível? :) A questão não é desempenho… e programar sem ORM não é mais difícil que usar os ORMs mais populares. Só exige um mínimo de conhecimento de dados. Se não formos utilizar a tecnologia que pode ter consequência negativa, qual usaremos? SQL? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Javeiros são um problema de forma geral, normalmente programam de forma estruturada em uma linguagem orientada a objeto... sou javeiro e o mais difícil é dizer a um que ele não esta fazendo da forma correta... imagina então tirar a facilidade do Hibernate, vixi A única coisa chata é escutar que desenvolvedor/programador é tudo igual. Existem os maus e os bons, como em tudo na vida. Tom Lane é um desenvolvedor/programador. Alguém aqui duvida de sua competência? E isso é apenas para ficar em um exemplo. Conheço alguns DBAs e sysadmins que só tem papo. São igual a esses Javeiros que vocês estão falando. Agora, será que todo DBA e sysadmin é igual? Será que existe Advogado honesto? E político? rs. Eu concordo que a maioria é que é um problema. Estão acostumados a arrastar e soltar e acabam denegrindo a imagem do resto. Claro que isso é apenas a minha humilde opnião. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11/09/2012 15:41, Vinicius Santos escreveu: Javeiros são um problema de forma geral, normalmente programam de forma estruturada em uma linguagem orientada a objeto... sou javeiro e o mais difícil é dizer a um que ele não esta fazendo da forma correta... imagina então tirar a facilidade do Hibernate, vixi A única coisa chata é escutar que desenvolvedor/programador é tudo igual. Existem os maus e os bons, como em tudo na vida. generalizei pq não quero levantar defuntos conhecidos meus... hehehehe... e você esta coberto de razão. Tom Lane é um desenvolvedor/programador. Alguém aqui duvida de sua competência? E isso é apenas para ficar em um exemplo. Não se doa, não duvido da capacidade de ninguém. Conheço alguns DBAs e sysadmins que só tem papo. São igual a esses Javeiros que vocês estão falando. Agora, será que todo DBA e sysadmin é igual? Será que existe Advogado honesto? E político? rs. poderia. Eu concordo que a maioria é que é um problema. Estão acostumados a arrastar e soltar e acabam denegrindo a imagem do resto. Claro que isso é apenas a minha humilde opnião. sem dúvidas... ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Flávio Alves Granato flavio.gran...@gmail.com: Javeiros são um problema de forma geral, normalmente programam de forma estruturada em uma linguagem orientada a objeto... Exatamente o que se falava de coboleiros… programavam Cobol em qualquer linguagem, o que significava o chamado ‘código espaguete’ (não estruturado) tanto nas versões estruturadas do Cobol quanto nas linguagens estruturadas de nascença. Bem que dizem que Java é o novo Cobol. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Vinicius Santos vinicius.santos.li...@gmail.com: Javeiros são um problema de forma geral, normalmente programam de forma estruturada em uma linguagem orientada a objeto... sou javeiro e o mais difícil é dizer a um que ele não esta fazendo da forma correta... imagina então tirar a facilidade do Hibernate, vixi A única coisa chata é escutar que desenvolvedor/programador é tudo igual. Ninguém falou isso. O colega deixou claro que foi uma generalização, e que ele mesmo é javeiro. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11 de setembro de 2012 15:40, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Pois se você conseguir utilizar os argumentos corretos você consegue o que quiser. Isso seria o ideal: que os bons argumentos vencessem. Tudo depende. Depende de onde é. Depende da chefia. Depende da cultura da empresa. Depende da urgência. E depende também da tecnologia e da forma que a usamos. O ORM é bom? É ruim? Depende. Depende de como foi usado, se foi usado certo, do tempo disponível e do porte do projeto. Exemplo: Usar ORM para um pequeno aplicativo em uso por 10 pessoas ou para um ERP em uso por 1000 pessoas será diferente. Tudo vareia. :) Abraços, Eduardo Alexandre ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Bem como desenvolvedor Java, acho javeiro uma vulgarização, utilizador do Hibernate e apaixonado pelo Postgres, acho que devo me pronunciar. Apesar de muitos gostarem não há uma panaceia para todos os problemas em desenvolvimento. Ou melhor, não tenho conhecimento de ferramenta, linguagem ou framework que vá atender a todas as vontades e necessidades tantos do desenvolvedor como do dba e do cliente, infelizmente alguém sempre tem de sofrer. Mas, há saídas e formas interessantes de se fazer as coisas, que as deixam rápidas de desenvolver, seguras e com certa otimização. Infelizmente existe uma boa gama de programadores que acha que ou se usa tudo ou não se usa nada de uma ferramenta ORM. A meu ver e pela experiência que já tive fazendo alguns programas, há sempre a possibilidade de se mesclar os mundos. Muitas regras de negócios são e deveriam ser facilmente embutíveis no banco. O Hibernate, no caso, nos permite a maravilha de não ter que ficar fazendo o mapeamento objeto relacional, de modo manual, porém tem gente que acha que tudo tem de ser entregue ao mesmo. Há a possibilidade de se criar funções no Postgres e o fazer as chamadas pelo Hibernate, unindo assim as vantagens do Hibernate com a real função de um ótimo SGBD como Postgres. Evitando assim o uso, que ocorre atualmente, do banco como mero repositório de dados. Agilizando tanto o desenvolvimento quanto a manutenibilidade do mesmo, pois, estando as regras dentro do banco, a mudança ou correção de qualquer funcionalidade é mais rápida e limpa do que reescrever o código, seja em PHP, JAVA ou qualquer outra linguagem. Fora outras vantagens que vem a partir disso. Vejo que muitos programadores, atualmente, simplesmente jogam a responsabilidade de algo para cima de um ou outro framework e se der problema alega limitação do mesmo. O uso de chave compostas exige sim um pouco mais de trabalho no Hibernate mas, não é uma coisa impossível e muito menos inviável. Porém muitos programadores que já tive contato, pouco conhecem de banco, o que os impede - as vezes - de enxergar os problemas que estarão criando, pois acham muito mais prático usar chaves artificiais. O assunto de ORM sempre vai e volta aqui. Sinto se ofendi alguém mas esse é o meu relato com base na minha realidade e experiência. Bruno E. A. Silva. Analista de Sistemas. 2012/9/11 Eduardo Alexandre eduardog...@gmail.com: Em 11 de setembro de 2012 15:20, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Bem, vou pelo pensamento mais conservador. Se pode dar consequência então é de se pensar, pois pode dar consequência média e baixa pode dar problema a médio e longo prazo. Dois pontos: O desenvolvimento precisa atender a determinados níveis de qualidade e velocidade de desenvolvimento. Se houver desenvolvedores na lista, sabem o que é receber um pedido de um recurso mirabolante pra ontem e ser obrigado a cumprir esse prazo. Geralmente esse fato se repete dia após dia, sendo tudo urgente e pra ontem. Se eu for pensar no cenário ideal, diria que é melhor fazer o software na unha, otimizado para a melhor performance possível. Mas será que isso é possível? :) Se não formos utilizar a tecnologia que pode ter consequência negativa, qual usaremos? Abraços, Eduardo Alexandre ___ 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
Re: [pgbr-geral] Substituição dos ORM
Em 11 de setembro de 2012 15:40, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/11 Eduardo Alexandre eduardog...@gmail.com: O desenvolvimento precisa atender a determinados níveis de qualidade Esse é o problema! Há pouquíssimos ORM que tenham um mínimo de qualidade. Lembro do SQL Alchemy, do Python, e acho que o Diogo havia me dito que o Rails estava com um decente opcional na versão três. O problema não é nem tanto o ORM, mas como ele é vendido. O povo aqui no trampo usa Hibernate... e fica bom sim. Eles me mostraram como o hibernate evoluiu em algumas coisas e como dá para usar bem o cache dele a nosso favor e eles sabem que em muitas situações temos que passar por fora dele, e principalmente, nunca, NUNCA modelar a base pensando no seu ORM. A parte CRUD da aplicação pode usar um ORM sem problemas. Mas você tem de avaliar quanto da sua aplicação é CRUD simples e escarrado. Em grandes volumes de dados, consultas complexas, transações e concorrência o ORM acaba atrapalhando mais do que ajudando. Os vendedores não falam isso, né? E aí o mal já está feito. velocidade de desenvolvimento. Se houver desenvolvedores na lista, sabem o que é receber um pedido de um recurso mirabolante pra ontem e ser obrigado a cumprir esse prazo. Geralmente esse fato se repete dia após dia, sendo tudo urgente e pra ontem. Mas os ORMs geralmente atrasam o resultado, introduzindo problemas. Se eu for pensar no cenário ideal, diria que é melhor fazer o software na unha, otimizado para a melhor performance possível. Mas será que isso é possível? :) A questão não é desempenho… e programar sem ORM não é mais difícil que usar os ORMs mais populares. Só exige um mínimo de conhecimento de dados. Se não formos utilizar a tecnologia que pode ter consequência negativa, qual usaremos? SQL? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/http://tellesr.wordpress.com e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Select registros maiores que uma data
select dsc_historico,dat_ctr_inclusao from cartao_historico where id_cartao = 983421 order by dat_ctr_inclusao Acho que algo assim resolveria: select aprv.id_cartao -- Retorna os cartões com alteração após aprovação from cartao_historico aprv join cartao_historico salv_apos_aprov on salv_apos_aprov.id_cartao = aprv.id_cartao -- Retorna os cartões... and salv_apos_aprov.dsc_historico ilike 'Documento Salvo%'-- ... que foram alterados (coloque mais condições se necessário aqui) and salv_apos_aprov.dat_ctr_inclusao aprv.dat_ctr_inclusao-- ... após a data de aprovação where aprv.dsc_historico ilike 'Documento APROVADO%'; -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Bruno Silva bemanuel...@gmail.com: Bem como desenvolvedor Java, acho javeiro uma vulgarização Acho bom criar casca grossa, porque o termo ficará cada vez mais comum. Assim como houve coboleiros, clipeiros… Muitas regras de negócios são e deveriam ser facilmente embutíveis no banco. Idealmente todas, mas ainda não é possível… O Hibernate, no caso, nos permite a maravilha de não ter que ficar fazendo o mapeamento objeto relacional Exatamente — esse mapeamento não é necessário. Ergo, o Hibernate é contraprodutivo, não uma maravilha. Colocando noutros termos, o que corresponde a objeto é tipo, não tabela. O uso de chave compostas exige sim um pouco mais de trabalho no Hibernate Isso é que eu não entendo. Quando eu era coboleiro, isso era trivial e já era havia pelo menos duas décadas. Porque seria mais difícil em Java, tantas décadas depois? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
generalizei pq não quero levantar defuntos conhecidos meus... hehehehe... e você esta coberto de razão. Desculpe se eu dei a entender que foi uma resposta direta à vc. Não foi, foi apenas a minha opnião. Não estou dizendo de vc, mas tem muita gente que generaliza de maneira errada. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Select registros maiores que uma data
Em 11 de setembro de 2012 15:53, Marcone marconepe...@gmail.com escreveu: select dsc_historico,dat_ctr_inclusao from cartao_historico where id_cartao = 983421 order by dat_ctr_inclusao Acho que algo assim resolveria: select aprv.id_cartao -- Retorna os cartões com alteração após aprovação from cartao_historico aprv join cartao_historico salv_apos_aprov on salv_apos_aprov.id_cartao = aprv.id_cartao -- Retorna os cartões... and salv_apos_aprov.dsc_historico ilike 'Documento Salvo%'-- ... que foram alterados (coloque mais condições se necessário aqui) and salv_apos_aprov.dat_ctr_inclusao aprv.dat_ctr_inclusao-- ... após a data de aprovação where aprv.dsc_historico ilike 'Documento APROVADO%'; -- Marcone Peres - DBA http://www.linkedin.com/in/marconeperes @marconeperes (61) 8146-0028 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Valeu Marcone!!! Agora é só colocar umas condicoes a mais e resolvido. Grato a todos, Nelson ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
O problema não é nem tanto o ORM, mas como ele é vendido. O povo aqui no trampo usa Hibernate... e fica bom sim. Eles me mostraram como o hibernate evoluiu em algumas coisas e como dá para usar bem o cache dele a nosso favor e eles sabem que em muitas situações temos que passar por fora dele, e principalmente, nunca, NUNCA modelar a base pensando no seu ORM. Acho que o problema é exatamente este! Se o cara pensar assim: Como vou usar chaves naturais compostas se meu ORM tem dificuldades de trabalhar assim? Mais fácil criar um serial. E mesmo quando a tabela exigir apenas uma chave natural simples, o cara cria o serial por conveniência. É mais ou menos o que o Leandro vive dizendo. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Fábio Telles Rodriguez fabio.tel...@gmail.com: O problema não é nem tanto o ORM, mas como ele é vendido. Inclusive. Assim como tanta outra coisa, como agrupamento de servidores só para retomar uma discussão recente… O povo aqui no trampo usa Hibernate... Ih, só darem férias para o gajo e ele já tem o cérebro lavado! ;-) bom sim. Eles me mostraram como o hibernate evoluiu em algumas coisas Novidade para mim. Mas duvido que tenham mudado o problema principal, que é tentar mapear objetos com tabelas. Eu ia perguntar em que evoluiu, mas estou longe desse mundo e acho que nem ia entender mais. como dá para usar bem o cache dele a nosso favor Sim, mas não precisa dum ORM para fazer cache na aplicação, certo? e eles sabem que em muitas situações temos que passar por fora dele, e principalmente, nunca, NUNCA modelar a base pensando no seu ORM. Amém. A parte CRUD da aplicação pode usar um ORM sem problemas. Nem ganhos… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Vinicius Santos vinicius.santos.li...@gmail.com: e eles sabem que em muitas situações temos que passar por fora dele, e principalmente, nunca, NUNCA modelar a base pensando no seu ORM. Acho que o problema é exatamente este! Acho que esse é o maior problema, mas não o único… Se o cara pensar assim: Como vou usar chaves naturais compostas se meu ORM tem dificuldades de trabalhar assim? Mais fácil criar um serial. E mesmo quando a tabela exigir apenas uma chave natural simples, o cara cria o serial por conveniência. É mais ou menos o que o Leandro vive dizendo. Obrigado! ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11 de setembro de 2012 15:46, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Bem que dizem que Java é o novo Cobol. JAVA IS THE NEW COBOL. Sensacional. -- Atenciosamente, Alexsander da Rosa ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Alexsander Rosa alexsander.r...@gmail.com: Em 11 de setembro de 2012 15:46, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Bem que dizem que Java é o novo Cobol. JAVA IS THE NEW COBOL. Sensacional. …e verdadeiro… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Pessoal, pelo que vejo um ponto crucial no problema é o fato de que, programadores fazem cursos, ou estudam, programação e dba's estudam banco de dados. Acho que nos cursos que já fiz dá pra contar nos dedos - de uma mão - quantos dba fizeram algum curso de programação e vice-versa. Então vejo muito programador falando tolices quando se refere a banco e vice-versa. Cada um fica com uma idéia muito superficial da coisa. Num curso que fiz recentemente sobre BI vi o pessoal tendo muito trabalho para gerar seus dados por não terem um conhecimento maior do banco. Bruno E. A. Silva. Analista de Sistemas. 2012/9/11 Alexsander Rosa alexsander.r...@gmail.com: Em 11 de setembro de 2012 15:46, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Bem que dizem que Java é o novo Cobol. JAVA IS THE NEW COBOL. Sensacional. -- Atenciosamente, Alexsander da Rosa ___ 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
Re: [pgbr-geral] Substituição dos ORM
Muito bom erheehhe 2012/9/11 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org 2012/9/11 Alexsander Rosa alexsander.r...@gmail.com: Em 11 de setembro de 2012 15:46, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Bem que dizem que Java é o novo Cobol. JAVA IS THE NEW COBOL. Sensacional. …e verdadeiro… ___ 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
Re: [pgbr-geral] Substituição dos ORM
2012/9/11 Bruno Silva bemanuel...@gmail.com: Pessoal, pelo que vejo um ponto crucial no problema é o fato de que, programadores fazem cursos, ou estudam, programação e dba's estudam banco de dados. Não é bem assim. Quem passa por um curso técnico que seja tem obrigação de ver os dois, claro que não na mesma profundidade. O problema é que ninguém ensina dados direito… ou dão umas dicas de SQL, ou mostram estruturas de listas ligadas e coisas assim. Mas conceito, que é bom, lhufas. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11 de setembro de 2012 17:25, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Não é bem assim. Quem passa por um curso técnico que seja tem obrigação de ver os dois, claro que não na mesma profundidade. Concordo! O problema é que ninguém ensina dados direito… ou dão umas dicas de SQL, ou mostram estruturas de listas ligadas e coisas assim. Mas conceito, que é bom, lhufas. Alguns não ensinam direito e outros não se dedicam a aprender. Geralmente cada qual cuida do seu cada qual e há a falta de entender um pouco sobre o assunto relacionado. Abraços, Eduardo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Problema com versões de registros
Acho que você teria de verificar antes de fazer o seu update, de modo a atualizar apenas os campos modificados. Agora concordando com o Dutra, sem maiores detalhes fica dificil te ajudar. Bruno E. A. Silva. Analista de Sistemas. 2012/8/30 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: 2012/8/30 Carlos Antônio Pereira carlosanto...@utivida.com.br: Boa tarde, senhores. Boa tarde. Dicas: não envie mensagens HTML à lista, e não reaproveite mensagens já existentes. Crie uma nova mensagem, limpa, com texto puro. Em uma aplicação temos várias etapas feitas ao mesmo tempo por vários usuários. Realmente terás de estudar controle de transações… difícil entender tua situação com tão poucas informações. ___ 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
Re: [pgbr-geral] Substituição dos ORM
Só pra apimentar a discussão, hoje programo com 90% da regra de negócio no banco de dados (não interesse em portar pra outro banco). Pode ser não ser a melhor alternativa, mas é bem rapido pra desenvolver. Jean Domingues. De: Eduardo Alexandre eduardog...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Terça-feira, 11 de Setembro de 2012 14:55 Assunto: Re: [pgbr-geral] Substituição dos ORM Olá, Minha área primária é em desenvolvimento. Atualmente em PHP (principalmente com PHP e acesso a dados por PDO, em segundo usando o CodeIgniter com ORM) e com C# ASP.Net com e sem uso de ORM. Acho que toda tecnologia pode ser boa ou ruim. Inclusive o ORM que, se usado corretamente, não vejo consequências tão graves. Abraços, Eduardo Alexandre Em 11 de setembro de 2012 14:48, Flávio Alves Granato flavio.gran...@gmail.com escreveu: Em 11/09/2012 14:46, Eduardo Alexandre escreveu: Qual a linguagem e ORM usados? Não, não... é mais um esforço de concientização para as mudanças, por onde os senhores começam ou simplesmente tentam contornar o uso de ORM nas aplicações. ___ 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] PGDAY Campinas 2012 - Divulgação
Uma pena ser durante a semana em horario comercial (no meu caso). Date: Tue, 11 Sep 2012 20:37:40 -0300 From: matheusespan...@gmail.com To: pgbr-...@listas.postgresql.org.br; pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] PGDAY Campinas 2012 - Divulgação Pessoal, No dia 03 de outubro será realizado o PGDAY Campinas 2012 [1] O evento será na Unicamp. As inscrições já estão abertas na página do evento. Contamos com a presença da comunidade e divulgação em blogs, sites, twitter etc... [1] http://www.dextra.com.br/eventos/pgday-campinas-2012 @matheusespanhol#pgdayCPS -- Matheus Ricardo Espanhol --- Dextra Sistemas http://www.dextra.com.br/postgres/ ___ 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
Re: [pgbr-geral] [pgbr-dev] PGDAY Campinas 2012 - Divulgação
Guedes, tem como abrir uma pagina no p.o.b para colocar o evento? Em 11 de setembro de 2012 23:37, Matheus Ricardo Espanhol matheusespan...@gmail.com escreveu: Pessoal, No dia 03 de outubro será realizado o PGDAY Campinas 2012 [1] O evento será na Unicamp. As inscrições já estão abertas na página do evento. Contamos com a presença da comunidade e divulgação em blogs, sites, twitter etc... [1] http://www.dextra.com.br/eventos/pgday-campinas-2012 @matheusespanhol #pgdayCPS -- Matheus Ricardo Espanhol --- Dextra Sistemas http://www.dextra.com.br/postgres/ ___ pgbr-dev mailing list pgbr-...@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-dev -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/%7Etelles/ http://tellesr.wordpress.com e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [pgbr-dev] PGDAY Campinas 2012 - Divulgação
2012/9/12 Fábio Telles Rodriguez fabio.tel...@gmail.com: Guedes, tem como abrir uma pagina no p.o.b para colocar o evento? Envia pro David Fetter também, (pg week news) Itamar Reis Peixoto http://www.quebarato.com.br/perfil/itamarjp ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Substituição dos ORM
Em 11 de setembro de 2012 23:53, Jean Domingues ejdom...@yahoo.com.brescreveu: Só pra apimentar a discussão, hoje programo com 90% da regra de negócio no banco de dados (não interesse em portar pra outro banco). Pode ser não ser a melhor alternativa, mas é bem rapido pra desenvolver. Bacana, mas para mim que tenho uma carga de mais de 20GB por dia e mais de 4K de conexões simultâneas... isso não é uma boa ideia. A questão é simples: é fácil distribuir a carga em uma dúzia de servidores de aplicação. Distribuir a carga em bancos de dados não é nada fácil. Então se você concentra TODA a inteligência da aplicação no seu SGDB, você pode ter gargalos muito difíceis de resolver e vai ter de partir para uma forma de escalabilidade horizontal muito cedo. Ou seja, concentrar toda inteligência no SGDB não é só um problema em termos de portabilidade é um problema em termos de escalabilidade. Não tem bala de prata neste mercado. Cada caso é um caso. []s -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/%7Etelles/ http://tellesr.wordpress.com e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
