Re: [pgbr-geral] Substituição dos ORM
Em 12/09/2012 16:59, Guimarães Faria Corcete DUTRA, Leandro escreveu: Não tem necessidade dessa agressividade, como eu já disse em outro momento, vai existir de tudo sempre, até pessoas que acham que SGBD é legado... Pois é, mas eu não suporto a ignorância posando de mestra… Terapia? hehehe... Isso não é verdade há anos em PostgreSQL. Temos várias linguagem OO, funcionais e até OO e funcionais. Alguém realmente usa? E como! O David Fetter, por exemplo, fez muita coisa interessante em PL/Perl. E tem PL/Java, PL/pgPSM para conformidade com os padrões, PL/Scheme funcional… O que importa não é se há quem mais use. O que importa é se resolve os problemas que alguém possa ter… Outra inverdade. Vide, por exemplo, pg_pool e XC. Conhecimentos que estou adquirindo, mas em empresas que passei tem adotado escalar a aplicação e não o SGBD. Esse é o ponto: conhecimento. As faculdades Java (no dizer o Joel Spolski) não têm ajudado… Não senhor! As faculdades Java não ensinam nem Java quanto mais escalar aplicação... é o mercado mesmo que faz isso. E convenhamos é muito mais fácil hoje em homens/hora configurar uma aplicação para escalar do quê um SGBD, visto aqueles todos por menores que comentam na lista sobre XC, Cluster e affins... só para exemplo, dizer ao jboss que ele deve trabalhar em conjunto com outro jboss em outra máquina é questão de uma linha de configuração... Haha... uso ORM... tanto que é o motivo desta thread que abri... não criticar o não uso, mas saber quando é melhor o não uso e começo a entender, nem precisa enfatizar que o melhor uso de ORM é nunca, ou ao menos não por enquanto... Por aí… embora o Teles tenha dito que o Hibernate andou melhorando, e eu saiba que SQL Alchemy também não era tão ruim. Para meu entendimento, o que seria SGBD conter toda a lógica de negócios? Normalmente tenho feito de maneira que o SGBD confirme( check, constraints... ) as regras desenvolvidas na aplicação e não levando a aplicação a ser uma visão da base. Nem tanto ao mar, nem tanto a terra… A aplicação não precisa ser apenas uma visão. Há muita coisa importante no desenvolvimento de interface humana, fluxos de trabalho c. Mas as regras organizacionais (‘de negócio’) deveriam ficar o mais perto da base possível, e de preferência declarativamente. O Date tem até um livreto interessante a respeito, _What not How_. Há vários riscos conhecidos ao separar as regras da base. O mais óbvio é a dificuldade de garantir que todo acesso à base aplique as regras, o que costuma levar a dados inconsistentes e toda a dor de cabeça e custos decorrentes. Joguemos com as regras de fato, do mercado, a onda é criar um usuário, um esquema e milhares de tabelas neste banco de dados e a aplicação cuidar do acesso. Se o ideal é ficar perto da base, é outros quinhentos, eu não concordo pelo fato que base de dados é feito para guardar dados e não regras ( não disse validar regras ). É onde os NoSQL deslumbram algumas pessoas e com razão, eles só querem que o banco grave e retorne os dados o mais rápido possível, se a base vai ficar inconsistente ou não e seus problemas, ai são mais quinhentos... ___ 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/12 Eden Cardim e...@insoli.de: Esse formato com iniciais é bastante comum na usenet Ah, Usenet… não é que às vezes faz falta? e no gmane, onde esta lista está inscrita e cujo criador coincidentemente é criador do MUA que eu uso e que gera as tais referencias estranhas. Que seria? É configurável, por exemplo para ser mais econômico nos espaços à esquerda? No ano de 2012, é mais incomum emails em listas de discussões virem sem uma alternativa em HTML por conta do acesso via dispositivos móveis, mas se essa é a convenção *dessa* lista, ok, sem problemas. Em que isso ajudaria dispositivos móveis? Pelo contrário, o HTML é peso morto. ___ 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/12 Eden Cardim e...@insoli.de: O que tem a ver é que mapeadores facilitam a integração com pontos de entrada de dados em bibliotecas OO externas ao banco de dados que realizam as transformações, evitando assim que essa integração precise ser reimplementada por inteiro para cada projeto. O meu argumento é de que esse tipo de integração é uma aplicação perfeitamente válida de mapeadores, até dos mais ruins. Teria sido bom explicitar o argumento em vez de torcer o vocabulário por dias… Mas tudo o que provaste é que a parte bom dos mapeadores… é o que a gente não precisa deles para fazer… ___ 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/13 Flávio Alves Granato flavio.gran...@gmail.com: Em 12/09/2012 16:59, Guimarães Faria Corcete DUTRA, Leandro escreveu: Pois é, mas eu não suporto a ignorância posando de mestra… Terapia? hehehe... Talvez fosse o caso. Esse é o ponto: conhecimento. As faculdades Java (no dizer o Joel Spolski) não têm ajudado… Não senhor! As faculdades Java não ensinam nem Java quanto mais escalar aplicação... Sendo que, por definição — por mais que a decadência tenha tornado a definição obsoleta —, faculdades deviam ensinar os conceitos de lógica, algoritmos, dados e programação funcional, não os charlatanismos de OO ou especificidades de escalar (para cima ou para baixo). E convenhamos é muito mais fácil hoje em homens/hora configurar uma aplicação para escalar do quê um SGBD, visto aqueles todos por menores que comentam na lista sobre XC, Cluster e affins... Sim, mas é uma situação que muda a cada dia, com cada nova versão. Até porque o PostgreSQL é o primeiro SGBD livre sólido, e seu desenvolvimento tem se acelerado impressionantemente. Mas há um contraponto: essa facilidade é amiúde enganosa, porque acaba escondendo problemas que, quando aparecem, freqüentemente são catastróficos. Essa conta de homens/h acaba sendo pobre por não levar em conta que bons homens precisam de menos homens (e portanto horas) hoje, e geram menos necessidade de homens/h amanhã. só para exemplo, dizer ao jboss que ele deve trabalhar em conjunto com outro jboss em outra máquina é questão de uma linha de configuração... A dor de cabeça é que a tendência ao longo do tempo de vida do sistema é que (1) regras declarativas são muito mais fáceis de manter e muito mais sólidas que as procedurais e (2) dificilmente todas as transações eternamente passarão por esse grupo de servidores de aplicação, o que tende a gerar as famigeradas inconsistências. São riscos a se administrar — ou evitar, quando possível. eu não concordo pelo fato que base de dados é feito para guardar dados e não regras ( não disse validar regras ) Pois é, mas se tu não concordas é que não conheces os conceitos por trás das ferramentas que usas. As restrições de integridade, como mostram o livro do Date e outros mais, e como mostra uma análise lógica, nada mais são que regras organizacionais declaradas sob outro nome. E é muito mais eficiente garanti‐las junto aos dados que num sistema separado, com toda a latência, o consumo de banda, mudanças de contexto envolvidos. O ‘x’ da questão é justamente a distribuição da carga, que costumava ser cara, até porque associada a produtos proprietários, e só agora está chegando ao mundo livre. É onde os NoSQL deslumbram algumas pessoas e com razão, eles só querem que o banco grave e retorne os dados o mais rápido possível, se a base vai ficar inconsistente ou não e seus problemas, ai são mais quinhentos... A história é uma velha senhora, sempre a murmurar… (Portugal). Ou, quem não conhece a história é condenado a repeti‐la. Codd criou o modelo relacional justamente pelos problemas criados pela falta de SGBDs lógicos. OO volta aos SGBDs baseados em grafos, e NoSQL vai pelo mesmo caminho… Por isso o povo babou no Prevayler. Para minha vergonha, seu criador está ganhando dinheiro público vendendo seu /snake oil/, agora com roupagem de métodos ágeis… e quem o pode culpar, sendo que nossa sociedade perdeu o conhecimento crítico? ___ 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 13/09/2012 08:29, Guimarães Faria Corcete DUTRA, Leandro escreveu: E convenhamos é muito mais fácil hoje em homens/hora configurar uma aplicação para escalar do quê um SGBD, visto aqueles todos por menores que comentam na lista sobre XC, Cluster e affins... Sim, mas é uma situação que muda a cada dia, com cada nova versão. Até porque o PostgreSQL é o primeiro SGBD livre sólido, e seu desenvolvimento tem se acelerado impressionantemente. É uma boa notícia. só para exemplo, dizer ao jboss que ele deve trabalhar em conjunto com outro jboss em outra máquina é questão de uma linha de configuração... A dor de cabeça é que a tendência ao longo do tempo de vida do sistema é que (1) regras declarativas são muito mais fáceis de manter e muito mais sólidas que as procedurais e (2) dificilmente todas as transações eternamente passarão por esse grupo de servidores de aplicação, o que tende a gerar as famigeradas inconsistências. São riscos a se administrar — ou evitar, quando possível. Da mesma forma que os SGBDs estão evoluindo as plataformas de desenvolvimento também. Esta mais fácil e muit mais rápido construir aplicações que antigamente, logo é mais barato fazer de novo e consequentemente todas as transações passaram sim pelo sistema e serão validadas, exemplos não faltam e de cabeça cito duas: Marabraz e Porto Seguro, e contratar pessoas para fazer a carga nos novos sistemas ou dependendo do caso, deixá-lo simplismente morrer de inanição. Por você talvez não conhecer metodologias como DDD ( Domain Driven Design ) [1] é que você acha que só é fácil fazer no SGBD. Se falarmos em SOA ( Service-oriented_architecture )[2] então afirmaremos que independente de como a aplicação seja feita ela passará por estes serviços e será aplicado as regras. eu não concordo pelo fato que base de dados é feito para guardar dados e não regras ( não disse validar regras ) Pois é, mas se tu não concordas é que não conheces os conceitos por trás das ferramentas que usas. As restrições de integridade, como mostram o livro do Date e outros mais, e como mostra uma análise lógica, nada mais são que regras organizacionais declaradas sob outro nome. E é muito mais eficiente garanti‐las junto aos dados que num sistema separado, com toda a latência, o consumo de banda, mudanças de contexto envolvidos. O ‘x’ da questão é justamente a distribuição da carga, que costumava ser cara, até porque associada a produtos proprietários, e só agora está chegando ao mundo livre. Conheço sim, não sou DBA para escarafunchar ( se é que se escreve assim ) todas as funcionalidades do SGBD, mas fazendo uma ponderação, continuo apostando na facilidade da configuração em 1 linha do JBoss a esperar um SGBD chegar na mesma facilidade. Gostaria muito de ter esta dúvida, escalar horizontalmente a aplicação ou o SGBD, afinal de contas é uma questão de escolhas pois é muito fácil nos dois. Mas não tenho esta dúvida, hoje é na aplicação que reside esta facilidade logo não é uma escolha só minha. Latência é fácil de resolver com programação ( ops! ) pois um cache resolveria ,exemplo: todas as postagens no facebook são processadas em outros momentos e não no momento em que te avisou que foi gravada com sucesso, então você clica em salvar, postar, seja lá o que for e ele te avisa Postagem salva e te mostra em sua timeline, mas na realidade ele gravou em um repositório de dados próximo a aplicação e disparou uma outra thread para gravar no repositório físico, o que interessa é mostrar ao usuário que foi salvo, agora quanto não interessa pois vai ser gravado mesmo. Consumo de banda, é discutível pois ou esta embutido no custo do uso do sistema ou os servidores são separados por um cabo de par trançado em algum rack. Mudanças de contexto envolvido é transparente. É onde os NoSQL deslumbram algumas pessoas e com razão, eles só querem que o banco grave e retorne os dados o mais rápido possível, se a base vai ficar inconsistente ou não e seus problemas, ai são mais quinhentos... A história é uma velha senhora, sempre a murmurar… (Portugal). Ou, quem não conhece a história é condenado a repeti‐la. Veja bem, não estou diminuindo a importância do SGBD. Codd criou o modelo relacional justamente pelos problemas criados pela falta de SGBDs lógicos. OO volta aos SGBDs baseados em grafos, e NoSQL vai pelo mesmo caminho… E qual o problema? SGBDs relacionais estão no mesmo patamar que os SGBDs NoSQL em uma decisão de arquitetura de software, sim, é uma questão de assumir riscos ou não, mas estarão. Por isso o povo babou no Prevayler. Bleh! Desde quando fui a uma palestra em 2003 vi que era muito, muito pouco para o que estavam vendendo como solução. ( minha terapia não funcionou agora... hehehehe ) Para minha vergonha, compartilho da vergonha. seu criador está ganhando dinheiro público vendendo seu /snake oil/, agora com roupagem de métodos ágeis… putz, sofro com roupagens novas para os métodos ágeis... gosto de definir que o
Re: [pgbr-geral] Substituição dos ORM
Estou saindo da lista que já estou incomodando, então esta responderei em particular… 2012/9/13 Flávio Alves Granato flavio.gran...@gmail.com: Em 13/09/2012 08:29, Guimarães Faria Corcete DUTRA, Leandro escreveu: Sim, mas é uma situação que muda a cada dia, com cada nova versão. Até porque o PostgreSQL é o primeiro SGBD livre sólido, e seu desenvolvimento tem se acelerado impressionantemente. É uma boa notícia. […] ___ 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
GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Que seria? É configurável, por exemplo para ser mais econômico nos GF espaços à esquerda? Posso configurar isso sim, mas acho menos confuso assim. GF Em que isso ajudaria dispositivos móveis? Pelo contrário, o GF HTML é peso morto. Dentre outras coisas, a semântica do HTML permite que o dispositivo ajuste a largura do texto em colunas, assim cada dispositivo pode cuidar das quebras de linha por conta própria, invés de bagunçar tudo com as quebras de linha explícitas do text/plain e um leitor não pode simplesmente ignorar as quebras de linha porque pode ser elas tenham algum propósito específico, como a construção de tabelas. -- Eden Cardim +55 11 9644 8225 e...@insoli.de http://insoli.de ___ 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
Acho que estão derivando do assunto. Favor discutir formatação em outro tópico ou local. Concordo com o Dutra, pode até ficar melhor, mas para quem está acostumado nesse padrão fica confuso de ler. Vamos discutir isso em outro local e voltemos ao ORM! Bruno E. A. Silva. Analista de Sistemas. 2012/9/13 Eden Cardim e...@insoli.de: GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Que seria? É configurável, por exemplo para ser mais econômico nos GF espaços à esquerda? Posso configurar isso sim, mas acho menos confuso assim. GF Em que isso ajudaria dispositivos móveis? Pelo contrário, o GF HTML é peso morto. Dentre outras coisas, a semântica do HTML permite que o dispositivo ajuste a largura do texto em colunas, assim cada dispositivo pode cuidar das quebras de linha por conta própria, invés de bagunçar tudo com as quebras de linha explícitas do text/plain e um leitor não pode simplesmente ignorar as quebras de linha porque pode ser elas tenham algum propósito específico, como a construção de tabelas. -- Eden Cardim +55 11 9644 8225 e...@insoli.de http://insoli.de ___ 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/13 Bruno Silva bemanuel...@gmail.com Acho que estão derivando do assunto. Favor discutir formatação em outro tópico ou local. Concordo com o Dutra, pode até ficar melhor, mas para quem está acostumado nesse padrão fica confuso de ler. Vamos discutir isso em outro local e voltemos ao ORM! Bruno E. A. Silva. Analista de Sistemas. 2012/9/13 Eden Cardim e...@insoli.de: GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Que seria? É configurável, por exemplo para ser mais econômico nos GF espaços à esquerda? Posso configurar isso sim, mas acho menos confuso assim. GF Em que isso ajudaria dispositivos móveis? Pelo contrário, o GF HTML é peso morto. Dentre outras coisas, a semântica do HTML permite que o dispositivo ajuste a largura do texto em colunas, assim cada dispositivo pode cuidar das quebras de linha por conta própria, invés de bagunçar tudo com as quebras de linha explícitas do text/plain e um leitor não pode simplesmente ignorar as quebras de linha porque pode ser elas tenham algum propósito específico, como a construção de tabelas. -- Eden Cardim +55 11 9644 8225 e...@insoli.de http://insoli.de ___ 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 +1. Estava acompanhando a discussão, que estava extremamente rica. Ao pessoal do layout, http://www.ietf.org/rfc/rfc1855.txt. Att, Bruno ___ 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
Para essa discussão tenho os seguintes (humildes) comentários: O assunto é interminável devido a existência de tantas variáveis que não há como chegar a uma receita de bolo sobre o assunto. A melhor opção simplesmente não existe, depende do caso. Em determinadas situações ORM é um mal necessário, tanto para o desenvolvimento como para o negócio, pelos motivos que alguns colegas falaram. Além de facilitar a implementação e é inegável o ganho de tempo e consequentemente de dinheiro. Numa fábrica de software, por exemplo, quanto mais tempo se economiza mais rápido você entrega um produto (menos R$ investido em salário). Um sistema feito em pouco tempo, provavelmente terá pouca qualidade, mas aí começam as evoluções nos sistemas (mais R$ entrando como receita) e o ciclo se reinicia. (Por favor, não estou generalizando). Mas a verdade irrefutável é: Aplicações e linguagens vão e vem, novidades surgem a cada segundo, mas os dados são eternos, por extensão a lógica que os relaciona também (absorvendo as mudanças que o negócio possa ter). Hoje JAVA, PHP e outras OO com seus respectivos ORM's são a bola da vez, mas amanhã podem não ser e certamente não serão. Aí vem a decisão do gestor de apostar tudo na aplicação ou nas informações que movem seu empreendimento. ORM, lógica negocial no banco, noSQL, etc, etc, tem mercado para todos, onde alguns mercados agradam mais alguns do que outros. Pelo que pude observar essa discussão bateu o record da lista em número de respostas e para mim foi muito rica e valeu cada minuto investido na leitura dos e-mails dos colegas. É muito empolgante poder acompanhar discussões tão acirradas, apesar de eu não conseguir participar da lista tanto quanto gostaria. Ler esses e-mails é muito mais produtivo e rico do que ler todos os livros de TI de muitas livrarias por aí! :-) -- 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
GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Mas tudo o que provaste é que a parte bom dos mapeadores… é o que a GF gente não precisa deles para fazer… Precisar não precisamos nem de computadores. Mas mapeadores aceleram a integração com bibliotecas externas, então faz sim sentido fazer proveito disso em alguns casos, apesar do mantra anti-mapeador que permeia as comunidades de SGDBs. -- Eden Cardim +55 11 9644 8225 e...@insoli.de http://insoli.de ___ 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
Le 12/09/12 0:37-0300, Fábio Telles Rodriguez a écrit : 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. O que mostra que ainda não temos SGBDs distribuídos de verdade. Tomara que o Postgres XC venha a ser para o caso genérico — já é para casos (não muito) restritos. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (61) 9302 2691 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ 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 20:53, Jean Domingues escreveu: 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. Meu ponto de vista. Você trabalha quebrando um conceito que é o SoC ( Separation of Concerns ), basicamente cada macaco no seu galho. Me baseio nesta discussão [1] pois concordo plenamente com a última opinião. Irei reproduzir as palavras do autor do último post, para não termos que ir lá e depois voltar à lista para colocarmos pontos de vista. 1. Violação de princípios – Regra no banco viola o principio que chamamos de Soc (separation os concern) 2. Falta de portabilidade – Regra no banco não tem garantias de portabilidade entre diferentes vendores de SGDB. Vale lembrar que hoje SGDB já considerando LEGADO advento do NoSql. ## resalto que até a chegada do PostgreSQL 9.2 - Flávio Granato ## 3. Programação Pobre – regras no banco de dados não é OO e nem funcional, sendo assim não tem como usar recursos como classes, encapsulamento, agregação, composição, associação, herança e polimorfismo. 4. Performance Ruim – soluções com grande numero de acessos simultâneos podem facilmente derrubar um SGDB, uma vez que um banco de dados não tem todos os gerenciamentos de recursos e as otimizações devidas encontradas em MIDDLEWARE como resources pooling, passivation, clustering, etc… por Fernando Franzini. Minha experiência atual com esta questão banco x sistema ( aqui generalizo e não levo só a OO ) é que estou com um projeto nas mãos que tudo, literalmente tudo é uma procedure no banco, desde inserts a updates e selects mais trabalhosos e digo que não é nada produtivo, pois tudo tem que se criar uma procedure e desenvolver, se fosse por conta do desenvolvedor orientado pelo DBA ( em nosso projeto não existe mais o chapéu de DBA ) seria muito mais produtivo, pois paralelizaria o desenvolvimento e não concentraria somente em uma pessoa, estamos falando de equipe pequena 4 pessoas e de uma empresa que seu fim é desenvolver software para outras empresas. Não sei se me fiz entender bem. Lembro-vos que não estamos discutindo a opinião do Fernando Franzini... 1 http://www.tectura.com.br/topics/regras_de_negocio_banco_x_oo ___ 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 12/09/2012 06:45, Leandro Guimarães Faria Corcete DUTRA escreveu: Le 12/09/12 0:37-0300, Fábio Telles Rodriguez a écrit : 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. O que mostra que ainda não temos SGBDs distribuídos de verdade. Tomara que o Postgres XC venha a ser para o caso genérico — já é para casos (não muito) restritos. Uma ferramenta muito bem vinda, emendando com as novas características do PostgreSQL 9.2 mais XC. ___ 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/12 Flávio Alves Granato flavio.gran...@gmail.com: Uma ferramenta muito bem vinda, emendando com as novas características do PostgreSQL 9.2 mais XC. Justamente uma das limitações do XC hoje é não suportar tudo que o PostgreSQL suporta — imagino que principalmente das versões mais recentes? Já é um grande avanço rumo a um SGBD distribuído, mas ainda temos em situações em que não podemos pôr tudo na base de dados por falta de capacidade de distribuição de carga. Com a popularização do 9.2, mais escalável, e com os avanços nas versões futuras tanto do PostgreSQL quanto do XC, logo o Fábio não terá mais desculpa para tirar a lógica da base… Claro que, havendo mais recursos, eles logo serão consumidos. Então uma dinâmica que se estabelece é que novos desenvolvimentos sobre uma base sejam feitos com lógica fora da base, para não sobrecarregar o servidor. O problema é que, com novas máquinas e novas versões do PostgreSQL, logo torna‐se viável botar a lógica na base, mas aí ninguém mexe no legado. A distribuição permite que nova lógica seja colocada na base, mas num novo nó do grupo de servidores (/cluster/). ___ 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 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: Mas duvido que tenham mudado o problema principal [do hibernate], que é tentar mapear objetos com tabelas. Mas qual o problema? É certo que o mapeamento não é e nem tem como ser um para um entre classes e tabelas, mas me parece claro que cada classe no modelo vira uma tabela no banco, que uma hierarquia de classes pode ter uma tabela para cada classe ou uma tabela para N classes, dependendo de que classes no modelo devem ser persistentes, e que composições precisam de tabelas auxiliares. Você vê algo de errado, incompleto ou inconsistente nesse pensamento? -- Joao Morais ___ 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 12 de setembro de 2012 09:10, Joao Morais jcmorai...@gmail.comescreveu: 2012/9/11 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: Mas duvido que tenham mudado o problema principal [do hibernate], que é tentar mapear objetos com tabelas. Mas qual o problema? É certo que o mapeamento não é e nem tem como ser um para um entre classes e tabelas, mas me parece claro que cada classe no modelo vira uma tabela no banco, que uma hierarquia de classes pode ter uma tabela para cada classe ou uma tabela para N classes, dependendo de que classes no modelo devem ser persistentes, e que composições precisam de tabelas auxiliares. Você vê algo de errado, incompleto ou inconsistente nesse pensamento? Leia atentamente e reflita por um tempo. Quando eu li, me senti um pouco zonzo no começo http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch []s -- 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] Substituição dos ORM
Em 12 de setembro de 2012 08:41, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com: Uma ferramenta muito bem vinda, emendando com as novas características do PostgreSQL 9.2 mais XC. Justamente uma das limitações do XC hoje é não suportar tudo que o PostgreSQL suporta — imagino que principalmente das versões mais recentes? Já é um grande avanço rumo a um SGBD distribuído, mas ainda temos em situações em que não podemos pôr tudo na base de dados por falta de capacidade de distribuição de carga. Com a popularização do 9.2, mais escalável, e com os avanços nas versões futuras tanto do PostgreSQL quanto do XC, logo o Fábio não terá mais desculpa para tirar a lógica da base… Errado, muito errado. Eu convido as pessoas a lerem um pouco mais sobre clusters shared nothing antes de sair fazendo panaceia sobre o XC ou mesmo compará-lo com o Oracle RAC (que usa uma tecnologia completamente diferente). Para usar o XC para escalar em ambiente OLTP (isso exclui a replicação multi master automaticamente), você precisa de um particionamento cuidadoso de tabelas e uma modelagem cuidadosa. Então, se você continua jogando tudo em PL não vai escalar no XC, pois a arquitetura até agora não funciona assim. O XC resolve problemas de escalabilidade OLTP para aplicações simples com requisitos severos de gravação e concorrência. Não resolve problemas de complexidade de regras no SGDB. Claro que, havendo mais recursos, eles logo serão consumidos. Então uma dinâmica que se estabelece é que novos desenvolvimentos sobre uma base sejam feitos com lógica fora da base, para não sobrecarregar o servidor. O problema é que, com novas máquinas e novas versões do PostgreSQL, logo torna‐se viável botar a lógica na base, mas aí ninguém mexe no legado. A distribuição permite que nova lógica seja colocada na base, mas num novo nó do grupo de servidores (/cluster/). ___ 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] Substituição dos ORM
Pergunta, o RAC escala? Bruno E. A. Silva. Analista de Sistemas. Bacharel em Sistemas de Informação Pós-graduando em Gerência de Projetos Certified Scrum Master LPIC-1 SCJP, SE 6 Novell CLA / DCTS ECR DBA Postgres --- “A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.” - Sábio Desconhecido Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença! 2012/9/12 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 12 de setembro de 2012 08:41, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com: Uma ferramenta muito bem vinda, emendando com as novas características do PostgreSQL 9.2 mais XC. Justamente uma das limitações do XC hoje é não suportar tudo que o PostgreSQL suporta — imagino que principalmente das versões mais recentes? Já é um grande avanço rumo a um SGBD distribuído, mas ainda temos em situações em que não podemos pôr tudo na base de dados por falta de capacidade de distribuição de carga. Com a popularização do 9.2, mais escalável, e com os avanços nas versões futuras tanto do PostgreSQL quanto do XC, logo o Fábio não terá mais desculpa para tirar a lógica da base… Errado, muito errado. Eu convido as pessoas a lerem um pouco mais sobre clusters shared nothing antes de sair fazendo panaceia sobre o XC ou mesmo compará-lo com o Oracle RAC (que usa uma tecnologia completamente diferente). Para usar o XC para escalar em ambiente OLTP (isso exclui a replicação multi master automaticamente), você precisa de um particionamento cuidadoso de tabelas e uma modelagem cuidadosa. Então, se você continua jogando tudo em PL não vai escalar no XC, pois a arquitetura até agora não funciona assim. O XC resolve problemas de escalabilidade OLTP para aplicações simples com requisitos severos de gravação e concorrência. Não resolve problemas de complexidade de regras no SGDB. Claro que, havendo mais recursos, eles logo serão consumidos. Então uma dinâmica que se estabelece é que novos desenvolvimentos sobre uma base sejam feitos com lógica fora da base, para não sobrecarregar o servidor. O problema é que, com novas máquinas e novas versões do PostgreSQL, logo torna‐se viável botar a lógica na base, mas aí ninguém mexe no legado. A distribuição permite que nova lógica seja colocada na base, mas num novo nó do grupo de servidores (/cluster/). ___ 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://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 ___ 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 12 de setembro de 2012 10:26, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 12 de setembro de 2012 10:20, Bruno Silva bemanuel...@gmail.comescreveu: Pergunta, o RAC escala? Escala bem processamento. Em alguns casos (onde não houver hot blocks) escala bem com memória. Mas o milagre dos peixes que é escalar disco, isso ele não escala não. E por acaso existe algo que escale disco automaticamente pra vc? -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ 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
Cara essa thread tá muito boa. Bruno E. A. Silva. Analista de Sistemas. 2012/9/12 Fabrízio de Royes Mello fabriziome...@gmail.com: Em 12 de setembro de 2012 10:26, Fábio Telles Rodriguez fabio.tel...@gmail.com escreveu: Em 12 de setembro de 2012 10:20, Bruno Silva bemanuel...@gmail.com escreveu: Pergunta, o RAC escala? Escala bem processamento. Em alguns casos (onde não houver hot blocks) escala bem com memória. Mas o milagre dos peixes que é escalar disco, isso ele não escala não. E por acaso existe algo que escale disco automaticamente pra vc? -- Fabrízio de Royes Mello Consultoria/Coaching PostgreSQL Blog sobre TI: http://fabriziomello.blogspot.com Perfil Linkedin: http://br.linkedin.com/in/fabriziomello Twitter: http://twitter.com/fabriziomello ___ 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
"GF" == Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org writes: GF Há pouquíssimos ORM que tenham um mínimo de qualidade. GF Lembro do SQL Alchemy, do Python, e acho que o Diogo havia me dito que GF o Rails estava com um decente opcional na versão três. O DBIx::Class também é bastante razoável. GF Mas os ORMs geralmente atrasam o resultado, introduzindo problemas. Nem sempre, a armadilha é que eles aceleram um milestone, e depois atrasam outras, por isso a dificuldade de justificar o não-uso de um ORM prum gerente de projeto, ainda mais esses "gerentes" que trabalham ad hoc e chamam de "ágil". GF A questão não é desempenho… e programar sem ORM não é mais difícil que GF usar os ORMs mais populares. Só exige um mínimo de conhecimento de GF dados. Não é mais difícil, mas pode ser trabalhoso, e reconheço que em boa parte dos casos, não existe saída fácil. Mas existe um problema recorrente em desenvolvimento que é inflar os dados normalizados do banco pruma estrutura de dados sã que o teu software pode consumir, e vice-versa, uma abstração boa pra esse problema pode acelerar sim o desenvolvimento sem comprometer a qualidade do banco e das rotinas de acesso. Eden Cardim +55 11 9644 8225 e...@insoli.de Insolide Soluções de TI Ltda. ___ 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/12 Joao Morais jcmorai...@gmail.com: 2012/9/11 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: Mas duvido que tenham mudado o problema principal [do hibernate], que é tentar mapear objetos com tabelas. Mas qual o problema? O problema é que o equivalente de objeto é valor, e o equivalente de classe é tipo de dados (abstrato). Como OO não abstrai de verdade, o que acaba implementando é uma representação de um tipo de dados. O Chris Date tem algo a respeito, por exemplo em http://dbdebunk.blogspot.com.br/2012/08/type-vs-domain-and-class.html ou http://www.oreillynet.com/pub/a/network/2005/07/29/cjdate.html?page=2 Um bom debate em http://lambda-the-ultimate.org/node/3066 Na prática, os objetos deviam ser uma abstração, deixando que os programadores de aplicações reusassem objetos sem se preocupar com o que está dentro. Como a abstração não funciona, ganha‐se muito pouco mesmo no caso geral; e, no caso de base de dados, como além das deficiências do OO em geral ainda temos uma abstração falha (o SQL) sendo abstraído com um sistema ainda mais falho (OO), o resultado geralmente é uma perda. ___ 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/12 Eden Cardim e...@insoli.de: GF == Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org writes: Há pouquíssimos ORM que tenham um mínimo de qualidade. O DBIx::Class também é bastante razoável. Bom saber. Mas não farei a justiça de investigar o por quê de ser razoável. parte dos casos, não existe saída fácil. Mas existe um problema recorrente em desenvolvimento que é inflar os dados normalizados do banco pruma estrutura de dados sã que o teu software pode consumir, e Mas aí é um problema ou de um modelo ruim (inconsistente), ou incompleto (faltam as visões [VIEW]s que dêem os resumos que o programa precisa) ou de um programa ruim. Ou de qualquer combinação dessas três. Isso porque não há abstração de dados melhor que a relacional. OO é uma falsa abstração, na verdade ela volta para o físico o que, em SQL, é ao menos parcialmente lógico… vice-versa, uma abstração boa pra esse problema pode acelerar sim o desenvolvimento sem comprometer a qualidade do banco e das rotinas de acesso. O problema é que ORM não dá essa boa abstração, como acabo de (tentar) explicar alhures nesta discussã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
2012/9/12 Bruno Silva bemanuel...@gmail.com: Cara essa thread tá muito boa. modéstia=off Obrigado, obrigado… modéstia=on É que a lista tem gente muito boa… ___ 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/12 Fabrízio de Royes Mello fabriziome...@gmail.com: E por acaso existe algo que escale disco automaticamente pra vc? Qualquer coisa que não compartilhe disco… não há milagres. Hoje temos, além da opção SSD, o Postgre XC que caminha para ser distribuído — aliás minha memória parece querer me indicar que já é, pelo menos mais que o Oracle RAC. Que me lembre, o XC já não compartilha disco, estou errado? ___ 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 12/09/2012 11:17, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/9/12 Eden Cardim e...@insoli.de: GF == Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org writes: Há pouquíssimos ORM que tenham um mínimo de qualidade. O DBIx::Class também é bastante razoável. Bom saber. Mas não farei a justiça de investigar o por quê de ser razoável. parte dos casos, não existe saída fácil. Mas existe um problema recorrente em desenvolvimento que é inflar os dados normalizados do banco pruma estrutura de dados sã que o teu software pode consumir, e Mas aí é um problema ou de um modelo ruim (inconsistente), ou incompleto (faltam as visões [VIEW]s que dêem os resumos que o programa precisa) ou de um programa ruim. Ou de qualquer combinação dessas três. Isso porque não há abstração de dados melhor que a relacional. OO é uma falsa abstração, na verdade ela volta para o físico o que, em SQL, é ao menos parcialmente lógico… vice-versa, uma abstração boa pra esse problema pode acelerar sim o desenvolvimento sem comprometer a qualidade do banco e das rotinas de acesso. Teria com colocar um exemplo simples? Pq agora eu fiquei bem confuso... até consigo entender mas não visualizar em minhas rotinas diárias... ___ 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/12 Fábio Telles Rodriguez fabio.tel...@gmail.com: Em 12 de setembro de 2012 08:41, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: Com a popularização do 9.2, mais escalável, e com os avanços nas versões futuras tanto do PostgreSQL quanto do XC, logo o Fábio não terá mais desculpa para tirar a lógica da base… Errado, muito errado. Eu convido as pessoas a lerem um pouco mais sobre clusters shared nothing antes de sair fazendo panaceia sobre o XC ou mesmo compará-lo com o Oracle RAC (que usa uma tecnologia completamente diferente). Ô Teles, que balde de água fria… …mas confesso que meu ‘logo’ saiu como afirmação, quando devia ter saído como esperança apenas… Para usar o XC para escalar em ambiente OLTP (isso exclui a replicação multi master automaticamente), você precisa de um particionamento cuidadoso de tabelas Particionamento que também tem evoluído aos poucos, sendo um dos pontos em que ainda não temos toda a facilidade que algum concorrente proprietário já tem… e uma modelagem cuidadosa. Então, se você continua jogando tudo em PL não vai escalar no XC, pois a arquitetura até agora não funciona assim. Certo. Mas lembre que, idealmente, as regras organizacionais (de ‘negócio’) são declarativas, não procedurais. Ainda não estamos lá, óbvio… O XC resolve problemas de escalabilidade OLTP para aplicações simples com requisitos severos de gravação e concorrência. Não resolve problemas de complexidade de regras no SGDB. Isso seria resolvido consertando o SQL, implementando o que ainda falta do SQL no PostgreSQL, e eventualmente com um sucessor do SQL onde não dá para consertar. Coisa de 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
"Joao" == Joao Morais writes: Joao Mas qual o problema? É certo que o mapeamento não é e nem tem Joao como ser um para um entre classes e tabelas, mas me parece Joao claro que cada classe no modelo vira uma tabela no banco, que Joao uma hierarquia de classes pode ter uma tabela para cada classe Joao ou uma tabela para N classes, dependendo de que classes no Joao modelo devem ser persistentes, e que composições precisam de Joao tabelas auxiliares. Você vê algo de errado, incompleto ou Joao inconsistente nesse pensamento? Sim, veja a dificuldade que existe para se implementar herança, delegação e polimorfismo usando essa equivalência, até porque dentro de um banco relacional, essas abstrações não fazem muito sentido (desvio de impedância). É até possível de se fazer, assim como também é possível programar orientado a objetos em C, porém vai te dar muito mais trabalho. Eu acho mais correto usar o termo "transformar" do que "mapear", porque isso deixa a distinção entre tabelas/registros/colunas e classes/objetos/atributos. Eden Cardim +55 11 9644 8225 e...@insoli.de Insolide Soluções de TI Ltda. ___ 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 12/09/2012 11:12, Eden Cardim escreveu: Joao == Joao Morais writes: Joao Mas qual o problema? É certo que o mapeamento não é e nem tem Joao como ser um para um entre classes e tabelas, mas me parece Joao claro que cada classe no modelo vira uma tabela no banco, que Joao uma hierarquia de classes pode ter uma tabela para cada classe Joao ou uma tabela para N classes, dependendo de que classes no Joao modelo devem ser persistentes, e que composições precisam de Joao tabelas auxiliares. Você vê algo de errado, incompleto ou Joao inconsistente nesse pensamento? Sim, veja a dificuldade que existe para se implementar herança, delegação e polimorfismo usando essa equivalência, até porque dentro de um banco relacional, essas abstrações não fazem muito sentido (desvio de impedância). É até possível de se fazer, assim como também é possível programar orientado a objetos em C, porém vai te dar muito mais trabalho. Eu acho mais correto usar o termo transformar do que mapear, porque isso deixa a distinção entre tabelas/registros/colunas e classes/objetos/atributos. Lendo os artigos enviados pelos amigos, eu trocaria tabelas/registro/dominio e classes/objetos/Tipos. Estou certo? ___ 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
#+BEGIN_EXAMPLE GF == Guimarães Faria Corcete DUTRA, Leandro writes: #+END_EXAMPLE #+BEGIN_EXAMPLE GF Mas aí é um problema ou de um modelo ruim (inconsistente), ou GF incompleto (faltam as visões [VIEW]s que dêem os resumos que o GF programa precisa) ou de um programa ruim. Ou de qualquer combinação GF dessas três. #+END_EXAMPLE Nem sempre, as vezes o domínio do negócio utiliza um formato mais adequado pra manipulação dos dados num meio fora do banco relacional, seja por abstração ou custo de implementação. Por exemplo, um grafo renderizado para SVG, é muito melhor transformar os dados do grafo dentro do banco em algum formato aceito por uma biblioteca que cuide da tarefa de gerar o SVG pra você. O que você está alegando é que o texto do SVG (ou o binário de um PNG) teria que sair pronto de dentro do banco com uma única consulta produzida por uma view ou função, e eu até concordo, o problema é que isso nem sempre prático ou barato em termos de engenharia. Por exemplo, já mencionaram numa outra thread que essa abordagem não escala bem. Esse trabalho de ETL e integração com o mundo externo encontra problemas recorrentes, e por isso faz sentido ter bibliotecas que abstraiam esses problemas. Desde que isso não influencie o projeto ideal do banco com idéias infundandas, não há problema algum. #+BEGIN_EXAMPLE GF Isso porque não há abstração de dados melhor que a relacional. #+END_EXAMPLE Há controvérsias, novamente, o que eu entendo é que isso depende do meio onde o acesso a dados está sendo feito. Por exemplo, árvores implementadas através de ponteiros são a melhor forma de se abstrair dados hierarquicos em memória, em diversos casos, e por isso vale a pena extrair a árvore de dentro do banco e reconstruí-la em memória para depois executar a lógica de negócio. Talvez o que você quis dizer é que não há abstração de dados melhor para persistir dados genéricos, e eu concordo plenamente (mesmo assim, ainda há controvérsias). #+BEGIN_EXAMPLE GF OO é uma falsa abstração, na verdade ela volta para o físico o GF que, em SQL, é ao menos parcialmente lógico… #+END_EXAMPLE Isso é análogo a afirmar que escrever código em binário é melhor do que escrever C porque está mais próximo do que acontece fisicamente, novamente, eu até concordo, sob a ótica de implementação ideal. O problema é que a nível de custo de projeto, raramente é viável implementar lógica de negócio num meio mais próximo do físico. #+BEGIN_EXAMPLE GF O problema é que ORM não dá essa boa abstração, como acabo de GF (tentar) explicar alhures nesta discussão. #+END_EXAMPLE ORM estritamente falando, talvez não, mas um toolkit de ETL pode vir a ser adequado em diversos casos sim. Eden Cardim +55 11 9644 8225 e...@insoli.de -- [[http://insoli.de][Insolide Soluções de TI Ltda.]] ___ 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/12 Eden Cardim e...@insoli.de: GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Mas aí é um problema ou de um modelo ruim (inconsistente), ou Metacomentário: que formato estranho! É padronizado algures? Nem sempre, as vezes o domínio do negócio utiliza um formato mais adequado pra manipulação dos dados num meio fora do banco relacional Não, é só ter o tipo adequado. E o PostgreSQL nos permite criar tipos… muitas das ditas extensões chamadas NoSQL para o PostgreSQL não passam de novos tipos. O que não as diminui de modo algum; só fico ressabiado porque ao falar de extensões NoSQL em vez de tipos SQL acabamos por diminuir indevidamente o SQL e, por extensão, o próprio modelo relacional (que já é bem mais poderoso que o SQL…). Por exemplo, um grafo renderizado para SVG, é muito melhor transformar os dados do grafo dentro do banco em algum formato aceito por uma biblioteca que cuide da tarefa de gerar o SVG pra você. O que você está alegando é que o texto do SVG (ou o binário de um PNG) teria que sair pronto de dentro do banco com uma única consulta produzida por uma view ou função Não mesmo. Não entendi porque a base teria de gerar o SVG quando os dados do grafo estão na base. GF Isso porque não há abstração de dados melhor que a relacional. Há controvérsias, novamente Ainda não as encontrei por parte de quem conheça o modelo relacional. Normalmente quem controverte mal conhece SQL — conhece no máximo como programador, não como modelo de dados. o que eu entendo é que isso depende do meio onde o acesso a dados está sendo feito. Por exemplo, árvores implementadas através de ponteiros são a melhor forma de se abstrair dados hierarquicos em memória, em diversos casos, e por isso vale a pena extrair a árvore de dentro do banco e reconstruí-la em memória para depois executar a lógica de negócio. Até aí morreu o Neves. Novamente, qual o problema de transformar os dados fora da base? Isso nada tem a ver com as regras organizacionais (‘de negócio’), ou com o mapeamento OR. Talvez o que você quis dizer é que não há abstração de dados melhor para persistir dados genéricos Não há ‘dados genéricos’. O que há é uma autolimitação por parte de quem não sabe criar tipos… GF OO é uma falsa abstração, na verdade ela volta para o físico o GF que, em SQL, é ao menos parcialmente lógico… Isso é análogo a afirmar que escrever código em binário é melhor do que escrever C porque está mais próximo do que acontece fisicamente, Pelo contrário, o SQL é mais abstrato. Ou não entendi o que quiseste dizer? ORM estritamente falando, talvez não, mas um toolkit de ETL pode vir a ser adequado em diversos casos sim. Nunca falei nada contra ETL… ___ 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
#+BEGIN_EXAMPLE GF == Guimarães Faria Corcete DUTRA, Leandro writes: #+END_EXAMPLE #+BEGIN_EXAMPLE GF O problema é que o equivalente de objeto é valor, e o equivalente de GF classe é tipo de dados (abstrato). #+END_EXAMPLE Se você olhar pruma linguagem como OCaml, vai ver que isso nem sempre é verdade. #+BEGIN_EXAMPLE GF Um bom debate em http://lambda-the-ultimate.org/node/3066 #+END_EXAMPLE Ahá! Observe a menção a OCaml ;) -- Eden Cardim +55 11 9644 8225 e...@insoli.de [[http://insoli.de][Insolide Soluções de TI Ltda.]] ___ 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
#+BEGIN_EXAMPLE
FG == Flávio Alves Granato writes:
#+END_EXAMPLE
#+BEGIN_EXAMPLE
FG Teria com colocar um exemplo simples? Pq agora eu fiquei bem confuso...
FG até consigo entender mas não visualizar em minhas rotinas diárias...
#+END_EXAMPLE
Um problema recorrente, por exemplo, é transformar isso:
#+BEGIN_EXAMPLE
| foo | bar |
|-+-|
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
#+END_EXAMPLE
Em isso (JSON):
#+BEGIN_EXAMPLE
{1:[1,2,3]}
#+END_EXAMPLE
Isso é uma das coisas que o
[[https://metacpan.org/module/DBIx::Class][DBIx::Class]] faz, seguindo
a especificação que você der. Em 5 minutos um desenvolvedor júnior
recém-contratado consegue fazer. O ideal mesmo, estritamente falando,
seria entregar isso prum DBA certificado fazer, só que vai custar 10
vezes mais por algo que não vai ficar 10x melhor.
--
Eden Cardim
+55 11 9644 8225
e...@insoli.de
[[http://insoli.de][Insolide Soluções de TI Ltda.]]
___
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/12 Flávio Alves Granato flavio.gran...@gmail.com: Lendo os artigos enviados pelos amigos, eu trocaria tabelas/registro/dominio e classes/objetos/Tipos. Estou certo? Não entendi o que seria essa troca? ___ 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 12/09/2012 15:10, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com: Lendo os artigos enviados pelos amigos, eu trocaria tabelas/registro/dominio e classes/objetos/Tipos. Estou certo? Não entendi o que seria essa troca? Não se preocupe, foi um devaneio meu. :-) ___ 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/12 Joao Morais jcmorai...@gmail.com: me parece claro que cada classe no modelo vira uma tabela no banco Não. O conceito de classe corresponde a tipo, não tabela (relação). Pode haver um tipo relação (tabela), mas a correspondência é via tipo. Isso porque a relação é transparente, ao contrário do objeto. O encapsulamento corresponde ao conceito de tipo, que é um domínio e seus operadores, encapsulando as possíveis representações. Mais detalhes nos textos do Date, que constam dos URIs já postados nesta discussã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
2012/9/12 Eden Cardim e...@insoli.de:
Um problema recorrente, por exemplo, é transformar isso:
[…]
| 1 | 1 |
| 1 | 2 |
| 1 | 3 |
Em isso (JSON):
{1:[1,2,3]}
Mas isso não é abstração… ou perdi algo?
___
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/12 Flávio Alves Granato flavio.gran...@gmail.com: Você trabalha quebrando um conceito que é o SoC ( Separation of Concerns ), basicamente cada macaco no seu galho. Mas esse conceito não é válido aqui. Como ele se aplicaria ao caso? Parece mais uma regrinha generalizada… Me baseio nesta discussão [1] pois concordo plenamente com a última opinião. Extremamente desinformada, como tentarei demonstrar. 1. Violação de princípios – Regra no banco viola o principio que chamamos de Soc (separation os concern) Chamam incorretamente. Separação de aspectos (ou de escopo) é um conceito do Dijkstra. Tanto o autor quanto o conceito são amplamente mal interpretados. No caso, vem de _On the role of scientific thought_ http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html. A Wikipædia http://en.wikipedia.org/wiki/Separation_of_concerns#Origin cita: ‘Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have called the separation of concerns, which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by focusing one's attention upon some aspect: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.’ Para traduzir o essencial: “…para meu gosto é característico de todo pensamento inteligente… dispõe‐se a estudar profundamente um aspecto do sujeito isolado para sua própria consistência, sempre sabendo que se ocupa apenas com um dos aspectos. Sabemos que um programa tem de ser correto e podemos estudá‐lo somente desse ponto de vista; também sabemos que deve ser eficiente e podemos estudar sua eficiência noutro dia, por assim dizer. …o programa é desejável. Mas nada se ganha —pelo contrário!— ao abordar esses vários aspectos simultaneamente. É o que às vezes chamei ‘a separação das preocupações’ que, mesmo não perfeitamente possível, é ainda a única técnica efetiva disponível que conheço para organizar os pensamentos. Isso é o que quero dizer com ‘focar a atenção nalgum aspecto’: não significa ignorar os outros aspectos, é só fazer justiça ao fato de que do ponto de vista deste aspecto, o outro é irrelevante. É ser focado e ter mente aberta simultaneamente.” 2. Falta de portabilidade – Regra no banco não tem garantias de portabilidade entre diferentes vendores de SGDB. Certo, mas isso é um problema dos SGBDs proprietários e (ou) ruins, que não implementam os padrões… Vale lembrar que hoje SGDB já considerando LEGADO advento do NoSql. O que mostra que o autor é uma toupeira no que se refere a dados, além de não saber escrever. ## resalto que até a chegada do PostgreSQL 9.2 - Flávio Granato ## Isso nunca foi verdade. O PostgreSQL 9.2 simplesmente implementa mais tipos, diminuindo ainda mais os já ínfimos casos em que usar algo prerrelacional (que é o que o NoSQL é, no fundo) valia a pena. 3. Programação Pobre – regras no banco de dados não é OO e nem funcional, sendo assim não tem como usar recursos como classes, encapsulamento, agregação, composição, associação, herança e polimorfismo. Isso não é verdade há anos em PostgreSQL. Temos várias linguagem OO, funcionais e até OO e funcionais. 4. Performance Ruim – soluções com grande numero de acessos simultâneos podem facilmente derrubar um SGDB, uma vez que um banco de dados não tem todos os gerenciamentos de recursos e as otimizações devidas encontradas em MIDDLEWARE como resources pooling, passivation, clustering, etc… por Fernando Franzini. Outra inverdade. Vide, por exemplo, pg_pool e XC. estou com um projeto nas mãos que tudo, literalmente tudo é uma procedure no banco, desde inserts a updates e selects mais trabalhosos e digo que não é nada produtivo E isso nada tem a ver com a lógica estar na base. A lógica deve ser preferencialmente declarativa, e só quando limitações seja no padrão SQL, seja em nossa implementação, impedirem implementar declarativamente é que se deve recorrer a procedimentos. O uso generalizado de procedimentos indica falta de conhecimento. pois tudo tem que se criar uma procedure e desenvolver, se fosse por conta do desenvolvedor orientado pelo DBA ( em nosso projeto não existe mais o chapéu de
Re: [pgbr-geral] Substituição dos ORM
Em 12/09/2012 15:57, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2012/9/12 Flávio Alves Granato flavio.gran...@gmail.com: Você trabalha quebrando um conceito que é o SoC ( Separation of Concerns ), basicamente cada macaco no seu galho. Mas esse conceito não é válido aqui. Como ele se aplicaria ao caso? Parece mais uma regrinha generalizada… Me baseio nesta discussão [1] pois concordo plenamente com a última opinião. Extremamente desinformada, como tentarei demonstrar. 1. Violação de princípios – Regra no banco viola o principio que chamamos de Soc (separation os concern) Chamam incorretamente. Separação de aspectos (ou de escopo) é um conceito do Dijkstra. Tanto o autor quanto o conceito são amplamente mal interpretados. No caso, vem de _On the role of scientific thought_ http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD447.html. A Wikipædia http://en.wikipedia.org/wiki/Separation_of_concerns#Origin cita: ‘Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have called the separation of concerns, which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by focusing one's attention upon some aspect: it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.’ Para traduzir o essencial: “…para meu gosto é característico de todo pensamento inteligente… dispõe‐se a estudar profundamente um aspecto do sujeito isolado para sua própria consistência, sempre sabendo que se ocupa apenas com um dos aspectos. Sabemos que um programa tem de ser correto e podemos estudá‐lo somente desse ponto de vista; também sabemos que deve ser eficiente e podemos estudar sua eficiência noutro dia, por assim dizer. …o programa é desejável. Mas nada se ganha —pelo contrário!— ao abordar esses vários aspectos simultaneamente. É o que às vezes chamei ‘a separação das preocupações’ que, mesmo não perfeitamente possível, é ainda a única técnica efetiva disponível que conheço para organizar os pensamentos. Isso é o que quero dizer com ‘focar a atenção nalgum aspecto’: não significa ignorar os outros aspectos, é só fazer justiça ao fato de que do ponto de vista deste aspecto, o outro é irrelevante. É ser focado e ter mente aberta simultaneamente.” Entendo, mal interpretação minha. Mas para mim, 2. Falta de portabilidade – Regra no banco não tem garantias de portabilidade entre diferentes vendores de SGDB. Certo, mas isso é um problema dos SGBDs proprietários e (ou) ruins, que não implementam os padrões… Vale lembrar que hoje SGDB já considerando LEGADO advento do NoSql. O que mostra que o autor é uma toupeira no que se refere a dados, além de não saber escrever. Não tem necessidade dessa agressividade, como eu já disse em outro momento, vai existir de tudo sempre, até pessoas que acham que SGBD é legado... ## resalto que até a chegada do PostgreSQL 9.2 - Flávio Granato ## Isso nunca foi verdade. O PostgreSQL 9.2 simplesmente implementa mais tipos, diminuindo ainda mais os já ínfimos casos em que usar algo prerrelacional (que é o que o NoSQL é, no fundo) valia a pena. concordo. Mas por isso ressaltei... NoSQL é recalque de programador que acha que base de dado deva ser algo burro, do tipo toma e me dá... 3. Programação Pobre – regras no banco de dados não é OO e nem funcional, sendo assim não tem como usar recursos como classes, encapsulamento, agregação, composição, associação, herança e polimorfismo. Isso não é verdade há anos em PostgreSQL. Temos várias linguagem OO, funcionais e até OO e funcionais. Alguém realmente usa? Se o padrão de fato é PL/PgSQL, então concordo e concordo também que é uma generalização, se não usam as linguagens citas como alternativas, ai são outros quinhetos. 4. Performance Ruim – soluções com grande numero de acessos simultâneos podem facilmente derrubar um SGDB, uma vez que um banco de dados não tem todos os gerenciamentos de recursos e as otimizações devidas encontradas em MIDDLEWARE como resources pooling, passivation, clustering, etc… por Fernando Franzini. Outra inverdade. Vide, por exemplo, pg_pool e XC. Conhecimentos que
Re: [pgbr-geral] Substituição dos ORM
GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Mas isso não é abstração… ou perdi algo? É um processo abstraível sim… E é exatamente o ponto onde eu quero chegar. Não tem porque reimplementar essa transformação quando você pode abstrair isso com uma biblioteca e economizar com a implementação. É onde um ORM (ressaltando que não gosto dessa terminologia) decente pode trazer benefício. Eden Cardim +55 11 9644 8225 e...@insoli.de -- [Insolide Soluções de TI Ltda.]: http://insoli.de ___ 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/12 Flávio Alves Granato flavio.gran...@gmail.com: Mas para mim, A frase veio truncada… Vale lembrar que hoje SGDB já considerando LEGADO advento do NoSql. O que mostra que o autor é uma toupeira no que se refere a dados, além de não saber escrever. Não tem necessidade dessa agressividade, como eu já disse em outro momento, vai existir de tudo sempre, até pessoas que acham que SGBD é legado... Pois é, mas eu não suporto a ignorância posando de mestra… Isso não é verdade há anos em PostgreSQL. Temos várias linguagem OO, funcionais e até OO e funcionais. Alguém realmente usa? E como! O David Fetter, por exemplo, fez muita coisa interessante em PL/Perl. E tem PL/Java, PL/pgPSM para conformidade com os padrões, PL/Scheme funcional… O que importa não é se há quem mais use. O que importa é se resolve os problemas que alguém possa ter… Outra inverdade. Vide, por exemplo, pg_pool e XC. Conhecimentos que estou adquirindo, mas em empresas que passei tem adotado escalar a aplicação e não o SGBD. Esse é o ponto: conhecimento. As faculdades Java (no dizer o Joel Spolski) não têm ajudado… Haha... uso ORM... tanto que é o motivo desta thread que abri... não criticar o não uso, mas saber quando é melhor o não uso e começo a entender, nem precisa enfatizar que o melhor uso de ORM é nunca, ou ao menos não por enquanto... Por aí… embora o Teles tenha dito que o Hibernate andou melhorando, e eu saiba que SQL Alchemy também não era tão ruim. Para meu entendimento, o que seria SGBD conter toda a lógica de negócios? Normalmente tenho feito de maneira que o SGBD confirme( check, constraints... ) as regras desenvolvidas na aplicação e não levando a aplicação a ser uma visão da base. Nem tanto ao mar, nem tanto a terra… A aplicação não precisa ser apenas uma visão. Há muita coisa importante no desenvolvimento de interface humana, fluxos de trabalho c. Mas as regras organizacionais (‘de negócio’) deveriam ficar o mais perto da base possível, e de preferência declarativamente. O Date tem até um livreto interessante a respeito, _What not How_. Há vários riscos conhecidos ao separar as regras da base. O mais óbvio é a dificuldade de garantir que todo acesso à base aplique as regras, o que costuma levar a dados inconsistentes e toda a dor de cabeça e custos decorrentes. ___ 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/12 Eden Cardim e...@insoli.de: Não tem porque reimplementar essa transformação quando você pode abstrair isso com uma biblioteca e economizar com a implementação. É onde um ORM (ressaltando que não gosto dessa terminologia) decente pode trazer benefício. Mas essa transformação não tem nada a ver com ORM! Json não é particularmente orientado a objetos! ___ 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
JSON não é orientado mesmo. E sinceramente, pode ser ótimo pro
desenvolvedor no momento que tá criando. Fico imaginando a manutenção
disso uns 3 anos depois, o cara olha o código e vê lá { '1', { sdfsd
,dsf s },{ sdf123,} }
Bruno E. A. Silva.
Analista de Sistemas.
2012/9/12 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org:
2012/9/12 Eden Cardim e...@insoli.de:
Não tem porque reimplementar essa transformação quando você pode abstrair
isso com uma biblioteca e economizar com a implementação. É onde um ORM
(ressaltando que não gosto dessa terminologia) decente pode trazer
benefício.
Mas essa transformação não tem nada a ver com ORM! Json não é
particularmente orientado a objetos!
___
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/12 Bruno Silva bemanuel...@gmail.com:
JSON não é orientado mesmo. E sinceramente, pode ser ótimo pro
desenvolvedor no momento que tá criando. Fico imaginando a manutenção
disso uns 3 anos depois, o cara olha o código e vê lá { '1', { sdfsd
,dsf s },{ sdf123,} }
Ô saudades dos arquivos seqüenciais do /mainframe/, com colunas fixas
(tabuladas)… ;-)
___
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
Éguas Dutra, eu nunca cheguei a trabalhar diretamente, mas depois de
ver o cara usar a calculadora pra definir o tamanho do arquivo a ser
alocado, vi que a coisa era complicada!
Bruno E. A. Silva.
Analista de Sistemas.
Bacharel em Sistemas de Informação
Pós-graduando em Gerência de Projetos
Certified Scrum Master
LPIC-1
SCJP, SE 6
Novell CLA / DCTS ECR
DBA Postgres
---
“A caixa dizia: Requer MS Windows ou superior. Então instalei Linux.”
- Sábio Desconhecido
Alguns prestam serviço/consultoria de Qualidade, os outros vendem licença!
2012/9/12 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org:
2012/9/12 Bruno Silva bemanuel...@gmail.com:
JSON não é orientado mesmo. E sinceramente, pode ser ótimo pro
desenvolvedor no momento que tá criando. Fico imaginando a manutenção
disso uns 3 anos depois, o cara olha o código e vê lá { '1', { sdfsd
,dsf s },{ sdf123,} }
Ô saudades dos arquivos seqüenciais do /mainframe/, com colunas fixas
(tabuladas)… ;-)
___
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/12 Bruno Silva bemanuel...@gmail.com: Éguas Dutra, eu nunca cheguei a trabalhar diretamente, mas depois de ver o cara usar a calculadora pra definir o tamanho do arquivo a ser alocado, vi que a coisa era complicada! Nada, era a própria simplicidade… cheio de limitações e ineficiências, mas para os casos gerais, como era o sistema de contas correntes do Itaú, atendia às maravilhas e era extremamente transparente e fácil de depurar. ___ 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
GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Metacomentário: que formato estranho! É padronizado algures? Meta-resposta: Existe padrão de resposta de email sancionado por alguma organização relevante? GF Não, é só ter o tipo adequado. E o PostgreSQL nos permite criar GF tipos… muitas das ditas extensões chamadas NoSQL para o PostgreSQL não GF passam de novos tipos. Certo, porém acrescentar novos tipos ou alterar os existentes sem downtime da base costuma, na minha experiência, ser administrativamente mais custoso do que atualizar código numa aplicação desacoplada. No caso, depende da competência administrativa dos recursos que você tem disponível pro projeto, se essa administração é trivial de realizar, você tem um bom motivo para usar tipos específicos de negócio, sim. Esse porém, nem sempre é o caso. GF Não mesmo. Não entendi porque a base teria de gerar o SVG quando os GF dados do grafo estão na base. Porque alguém precisa dos dados em forma de SVG, logo, alguma parte do sistema precisa transformar o grafo armazenado em relações num documento SVG. E não é trivial realizar essa transformação usando SQL, é menos trivial usar SQL para produzir um formato intermediário e depois converter esse formato no produto final (o SVG). É nessa transformação que um ORM (sic) é útil. GF Ainda não as encontrei por parte de quem conheça o modelo relacional. GF Normalmente quem controverte mal conhece SQL — conhece no máximo como GF programador, não como modelo de dados. 3 falácias retóricas na mesma sentença, assim fica difícil… Permance o fato: é controverso. GF Até aí morreu o Neves. Novamente, qual o problema de transformar os GF dados fora da base? Isso nada tem a ver com as regras organizacionais GF (‘de negócio’), ou com o mapeamento OR. Discordo, tem tudo a ver, porque quando se desenvolve orientado a objetos você precisa de um ponto de entrada dos dados no seu modelo OO, de uma forma ou de outra. Se você vai fazer isso manualmente ou não é uma outra questão, mas o mapeamento está sempre presente, usando ORM (sic) ou não. O problema está na forma como os ORM (sic) mais conhecidos abstraem essa transformação, mas é perfeitamente possível existirem abstrações razoáveis pra esse tipo de operação. GF Não há ‘dados genéricos’. O que há é uma autolimitação por parte de GF quem não sabe criar tipos… Há também uma limitação administrativa de se manter e atualizar tipos em ambientes de produção. O que eu geralmente faço é introduzir tipos onde se tem muita certeza da estabilidade dos requisitos de uma determinada parte do sistema, caso o ROI da introdução seja justificado. GF Pelo contrário, o SQL é mais abstrato. Ou não entendi o que quiseste dizer? Não concordo que SQL seja mais abstrato. É mais formal, porém não mais abstrato. Porém isso é difícil de medir objetivamente. Eden Cardim +55 11 9644 8225 e...@insoli.de -- [Insolide Soluções de TI Ltda.]: http://insoli.de ___ 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 12 de setembro de 2012 17:16, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2012/9/12 Bruno Silva bemanuel...@gmail.com: Éguas Dutra, eu nunca cheguei a trabalhar diretamente, mas depois de ver o cara usar a calculadora pra definir o tamanho do arquivo a ser alocado, vi que a coisa era complicada! Nada, era a própria simplicidade… cheio de limitações e ineficiências, mas para os casos gerais, como era o sistema de contas correntes do Itaú, atendia às maravilhas e era extremamente transparente e fácil de depurar. E dava pra fazer pesquisa com grep no console mesmo... mas no geral eu via mais desvantagens do que vantagens. O arquivo-texto por colunas é um extremo, um XML cheio de overhead é outro extremo, acho que o ideal é usar algo intermediário. -- 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
GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Mas essa transformação não tem nada a ver com ORM! Não tem se você não quiser enxergar dessa forma. Mas é perfeitamente razoável usar um ORM como um transformador resultset - JSON (ou XML, ou CSV, ou tabulado, ou SVG, etc.), usando as abstrações típicas de um ORM (sic) onde você entrega os dados do resultset pruma classe e ela cuida de serializar no formato que você quiser. O ORM (sic) diz qual(is) classe(s) é(são) responsável(is) por serializar esse conjunto de dados. Qual o problema dessa abordagem em particular? Eu vejo um problema quando os desenvolvedores tentam abstrair as tabelas em classes equivalentes, etc. Isso realmente dá vazão aos desenvolvedores modelarem o código de maneira errada. Mas quando você tem um mecanismo que abstrai as responsabilidades de transformação de dados vindos do banco, não há o menor problema, até porque você precisa fazer isso de um jeito ou de outro. Essa mesma abordagem pode ser feita sem orientação a objetos, em linguagens funcionais, por exemplo, você delegaria a responsabilidade pruma função. GF Json não é particularmente orientado a objetos! Engano seu e isso é off-topic, mas JSON é sigla de JavaScript *Object* Notation. Uma estrutura JSON mapeia diretamente prum protótipo de objeto em javascript que pode despachar métodos polimórficos, etc. etc. Eden Cardim +55 11 9644 8225 e...@insoli.de -- [Insolide Soluções de TI Ltda.]: http://insoli.de ___ 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
Regarding Re: Substituição dos ORM; Bruno Silva
bemanuel...@gmail.com adds:
BS JSON não é orientado mesmo. E sinceramente, pode ser ótimo pro
BS desenvolvedor no momento que tá criando. Fico imaginando a manutenção
BS disso uns 3 anos depois, o cara olha o código e vê lá { '1', { sdfsd
BS ,dsf s },{ sdf123,} }
Off-topic, mas vamos lá. A escolha de JSON como exemplo foi realmente
infeliz, porque não é um formato que me agrada muito. Mas é por esse
motivo que os dados canônicos ficam na base de dados em não nesse
formato horrendo. Infelizmente, existem muitas bibliotecas úteis,
testadas e funcionais que consomem esse formato e a economia no custo
de implementação mais do que justifica o débito técnico de adotá-las.
Eden Cardim
+55 11 9644 8225
e...@insoli.de
--
[Insolide Soluções de TI Ltda.]: http://insoli.de
___
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 12 de setembro de 2012 16:37, Eden Cardim e...@insoli.de escreveu: GF == Guimarães Faria Corcete DUTRA, Leandro writes: GF Metacomentário: que formato estranho! É padronizado algures? Meta-resposta: Existe padrão de resposta de email sancionado por alguma organização relevante? Sancionado não, mas existe uma etiqueta, ou netiqueta [1], que remete à RFC 1855 [2]. Realmente, teus e-mails estão difíceis de ler. Até essa criação de índices para os autores das frases foi criativo, mas estranho. Tente seguir o padrão que a maioria usa, pelo menos responder em texto puro sem HTML e sempre responder abaixo das perguntas. [1] http://pt.wikipedia.org/wiki/Netiqueta [2] http://pt.wikipedia.org/wiki/RFC -- TIAGO J. ADAMI http://www.adamiworks.com ___ 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
Le 2012-9-12 16h37, Eden Cardim a écrit : Meta-resposta: Existe padrão de resposta de email sancionado por alguma organização relevante? RFC 1855 e outros que me fogem à memória… Certo, porém acrescentar novos tipos ou alterar os existentes sem downtime da base costuma, na minha experiência, ser administrativamente mais custoso do que atualizar código numa aplicação desacoplada. Por outro lado, as inconsistências causadas por atualizações que passam por fora das regras que estão nas aplicações também… GF Não mesmo. Não entendi porque a base teria de gerar o SVG quando os GF dados do grafo estão na base. Porque alguém precisa dos dados em forma de SVG, logo, alguma parte do sistema precisa transformar o grafo armazenado em relações num documento SVG. E não é trivial realizar essa transformação usando SQL E isso não tem nada a ver com o que discutimos, uma vez que a transformação não tem nada a ver nem com o modelo relacional, nem com orientação a objetos. é menos trivial usar SQL para produzir um formato intermediário e depois converter esse formato no produto final (o SVG). É nessa transformação que um ORM (sic) é útil. E esse ‘sic’ aí mostra que estás forçando o termo. O que só está gerando confusão, e não contribui para a discussão. Use as bibliotecas que quiser, faça as transformações que quiser, mas isso não é mapeamento objeto-relacional. GF Ainda não as encontrei por parte de quem conheça o modelo relacional. GF Normalmente quem controverte mal conhece SQL — conhece no máximo como GF programador, não como modelo de dados. 3 falácias retóricas na mesma sentença, assim fica difícil… Permance o fato: é controverso. Precisas demonstrá-las. Mas não são falácias, são a experiência. Duas décadas dela. GF Até aí morreu o Neves. Novamente, qual o problema de transformar os GF dados fora da base? Isso nada tem a ver com as regras organizacionais GF (‘de negócio’), ou com o mapeamento OR. Discordo, tem tudo a ver, porque quando se desenvolve orientado a objetos você precisa de um ponto de entrada dos dados no seu modelo OO E o que isso tem a ver com essa transformação? Ou boiei… de uma forma ou de outra. Se você vai fazer isso manualmente ou não é uma outra questão, mas o mapeamento está sempre presente, usando ORM (sic) ou não. O problema está na forma como os ORM (sic) mais conhecidos abstraem essa transformação, mas é perfeitamente possível existirem abstrações razoáveis pra esse tipo de operação. Tu teimas em chamar meras transformações em mapeamento. Aí não dá para discutir, por simples falta de sentido quando se dá aos termos o significado que bem se entende, e não o convencional. Veja, se chamas qualquer biblioteca de transformação de ORM, não provas que ORM é necessário. Só que bibliotecas de transformação são necessárias. Há também uma limitação administrativa de se manter e atualizar tipos em ambientes de produção. O que eu geralmente faço é introduzir tipos onde se tem muita certeza da estabilidade dos requisitos de uma determinada parte do sistema, caso o ROI da introdução seja justificado. Certo. GF Pelo contrário, o SQL é mais abstrato. Ou não entendi o que quiseste dizer? Não concordo que SQL seja mais abstrato. É mais formal, porém não mais abstrato. Porém isso é difícil de medir objetivamente. Nem um pouco difícil. Bastante simples, até: em SQL, especificamos o que queremos, e podemos criar tipos abstratos de dados, isolando aplicações de muitas mudanças nos tipos e nas estruturas base, físicas e até, nalguma medida, lógicas; enquanto em OO temos de dizer como fazer, o que acaba por nos dar o problema das classes base mutantes… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ 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
Le 2012-9-12 17h52, Alexsander Rosa a écrit : E dava pra fazer pesquisa com grep no console mesmo... Na época eu nem conhecia grep, mas tinha um editor de textos, o ISPF/Edit ou algo assim, que matava muita coisa… tem até um clone, o THE — The Hessling Editor, mas me pareceu muito mais limitado e difícil de usar que o original. mas no geral eu via mais desvantagens do que vantagens. Como disse, cheio de limitações e ineficiências… O arquivo-texto por colunas é um extremo, um XML cheio de overhead é outro extremo, acho que o ideal é usar algo intermediário. Há intermediários e intermediários… -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ 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
Le 2012-9-12 18h7, Eden Cardim a écrit : Essa mesma abordagem pode ser feita sem orientação a objetos, em linguagens funcionais, por exemplo, você delegaria a responsabilidade pruma função. CQD. Não há nada especificamente OO nisso. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (61) 3546 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm ___ 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
TA == Tiago Adami writes: TA Sancionado não, mas existe uma etiqueta, ou netiqueta [1], que TA remete à RFC 1855 [2]. Realmente, teus e-mails estão difíceis de ler. TA Até essa criação de índices para os autores das frases foi criativo, TA mas estranho. Esse formato com iniciais é bastante comum na usenet e no gmane, onde esta lista está inscrita e cujo criador coincidentemente é criador do MUA que eu uso e que gera as tais referencias estranhas. TA Tente seguir o padrão que a maioria usa o padrão que a maioria usa depende da tua amostragem, fica difícil adivinhar o formato que agrada sem que haja uma indicação específica de formato. A intenção é que as mensagens tenham a maior legibilidade possível, e peço desculpas se não foi esse o caso. TA pelo menos responder em texto puro sem HTML Se você observar as mensagens (exceto essa que está apenas em text/plain pra te agradar), elas estão formatadas com multipart/alternative e multipart/related condizentes com os RFC 1521 e 2387, e dispõe de versões text/html e text/plain pra você escolher. Boa parte dos MUAs são configuráveis pra exibir um ou outro por default. No ano de 2012, é mais incomum emails em listas de discussões virem sem uma alternativa em HTML por conta do acesso via dispositivos móveis, mas se essa é a convenção *dessa* lista, ok, sem problemas. TA e sempre responder abaixo das perguntas. Se eu top-postei alguma vez, desculpa, aponte-me onde, pra não cometer mais o mesmo erro. -- Eden Cardim +55 11 9644 8225 e...@insoli.de http://insoli.de ___ 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
LD == Leandro DUTRA, Guimarães Faria Corcete writes: GF Até aí morreu o Neves. Novamente, qual o problema de transformar os GF dados fora da base? Isso nada tem a ver com as regras organizacionais GF (‘de negócio’), ou com o mapeamento OR. Discordo, tem tudo a ver, porque quando se desenvolve orientado a objetos você precisa de um ponto de entrada dos dados no seu modelo OO LD E o que isso tem a ver com essa transformação? Ou boiei… O que tem a ver é que mapeadores facilitam a integração com pontos de entrada de dados em bibliotecas OO externas ao banco de dados que realizam as transformações, evitando assim que essa integração precise ser reimplementada por inteiro para cada projeto. O meu argumento é de que esse tipo de integração é uma aplicação perfeitamente válida de mapeadores, até dos mais ruins. A alegação anterior era: EC parte dos casos, não existe saída fácil. Mas existe um problema EC recorrente em desenvolvimento que é inflar os dados normalizados do EC banco pruma estrutura de dados sã que o teu software pode consumir, e GF Mas aí é um problema ou de um modelo ruim (inconsistente), ou GF incompleto (faltam as visões [VIEW]s que dêem os resumos que o GF programa precisa) ou de um programa ruim. Ou de qualquer combinação GF dessas três. E isso nem sempre é verdade, muitas vezes os dados precisam de transformações complementares aos resumos das views, isso não implica em um programa ruim ou modelo incompleto, e é um caso onde é razoável utilizar mapeadores como mecanismo de integração. LD Nem um pouco difícil. Bastante simples, até: em SQL, especificamos o LD que queremos, e podemos criar tipos abstratos de dados, isolando LD aplicações de muitas mudanças nos tipos e nas estruturas base, físicas e LD até, nalguma medida, lógicas; enquanto em OO temos de dizer como fazer, LD o que acaba por nos dar o problema das classes base mutantes… Poderia se argumentar que existem implementações de OO que também possuem essas propriedades, caso fosse o tópico. Porém, seria irrelevante numa discussão objetiva, pois objetividade requer métrica. -- Eden Cardim +55 11 9644 8225 e...@insoli.de http://insoli.de ___ 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] 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] 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] 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] 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] 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] 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
