Re: [pgbr-geral] Função Update or Insert
Em 13 de outubro de 2011 18:43, desenvolvedor@gmail.com escreveu: Alexandre, poderia citar os malefícios das chaves artificiais? Supondo que você esteja se referindo a mim (Alexsander), o problema é o uso indiscriminado de chaves artificiais. Por exemplo, uma tabela de CEP não precisa ter uma coluna id_cep como PK, o próprio CEP é uma PK melhor. Neste caso, para saber o CEP de um logradouro é preciso um JOIN a mais. Outro exemplo: porque usar id_sexo numeric se podemos usar simplesmente sexo char(1) com um CHECK para garantir que seja M ou F? Muita gente usa ID em toda a base, de ponta a ponta, e isso é ruim. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Função Update or Insert
2011/10/14 Alexsander Rosa alexsander.r...@gmail.com Em 13 de outubro de 2011 18:43, desenvolvedor@gmail.com escreveu: Alexandre, poderia citar os malefícios das chaves artificiais? Supondo que você esteja se referindo a mim (Alexsander), o problema é o uso indiscriminado de chaves artificiais. Por exemplo, uma tabela de CEP não precisa ter uma coluna id_cep como PK, o próprio CEP é uma PK melhor. Neste caso, para saber o CEP de um logradouro é preciso um JOIN a mais. Outro exemplo: porque usar id_sexo numeric se podemos usar simplesmente sexo char(1) com um CHECK para garantir que seja M ou F? Muita gente usa ID em toda a base, de ponta a ponta, e isso é ruim. -- Atenciosamente, Alexsander da Rosa http://rednaxel.com ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII CentroMairiporãSP0760 Rua XV de NovembroCentroMairiporãSP0760 Vou cirar um outro exemplo calssico, Nota Fiscal, qdo a NF chegar a 999.999 ela volta ao 1 e muda a série, quem coloca NF como PK ja esta cometendo um erro, o ideal seria NF+DataEmissão ou NF+Serie Na minha opnião tem que ter muito cuidado com relação a chaves etc. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/14 Charles Viana charles.vi...@gmail.com: Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII Centro Mairiporã SP 0760 Rua XV de Novembro Centro Mairiporã SP 0760 Mas aí é uma tabela de endereços, não de CEPs. Vou cirar um outro exemplo calssico, Nota Fiscal, qdo a NF chegar a 999.999 ela volta ao 1 e muda a série, quem coloca NF como PK ja esta cometendo um erro, o ideal seria NF+DataEmissão ou NF+Serie Normal, uma chave composta é tranqüilo. Na minha opnião tem que ter muito cuidado com relação a chaves etc. E que cuidados recomendarias? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 14 de outubro de 2011 14:25, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/14 Charles Viana charles.vi...@gmail.com: Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII Centro Mairiporã SP 0760 Rua XV de Novembro Centro Mairiporã SP 0760 Mas aí é uma tabela de endereços, não de CEPs. Exato. No site dos Correios, se você pesquisar por 0760 vem apenas a cidade de Mairiporã. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Função Update or Insert
From: l...@dutras.org Date: Fri, 14 Oct 2011 14:25:13 -0300 To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Função Update or Insert 2011/10/14 Charles Viana charles.vi...@gmail.com: Voce citou um bom exemplo, no caso de CEP cidade onde o cep pode repetir até 2 vezes ou mais. Exemplo: Rua Pio XII CentroMairiporãSP0760 Rua XV de NovembroCentroMairiporãSP0760 Mas aí é uma tabela de endereços, não de CEPs. Exato. Na tabela de CEPs cada CEP é único. O que não se pode confundir é a relação entre CEP e logradouro, onde um único CEP pode ser referenciado por mais de um logradouro (como mostrado acima), no caso de CEPs com sufixo 000 em algumas localidades (vide [1]). [1] http://www.correios.com.br/servicos/cep/cep_estrutura.cfm Atenciosamente, Marçal de Lima Hokama ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 14-10-2011 14:54, Marcal Hokama escreveu: Exato. Na tabela de CEPs cada CEP é único. O que não se pode confundir é a relação entre CEP e logradouro, onde um único CEP pode ser referenciado por mais de um logradouro (como mostrado acima), no caso de CEPs com sufixo 000 em algumas localidades (vide [1]). E o cep que está para um determinado endereço pode não ser o mesmo cep do ano que vem, notadamente nas cidades que tem sua população crescendo mais do que o previsto pelos correios. Novos ceps são criados, e velhos são substituídos sem que o antigo endereço tenha saído do lugar, reestruturações são feitas a todo o instante. Faixas de cep são divididas entre os estados, municípios, bairros, sub-regiões do bairro e essa subdivisão muda cada vez que é construída uma grande avenida ou algum extensão adjacente ao bairro. Eu tenho convivido com ceps a minha vida toda e tenho tentado acompanhar as mazelas dos correios, já que minha atividade princípua está no ramo de logística. O Cep não é uma entidade, nem chave natural de entidade alguma é apenas o atributo de um endereço. Primeiro, em cidades pequenas que tenham cep único, você não consegue dar um cep diferente para cada endereço, logo ele não identifica unicamente uma entidade endereço. Você também não pode usá-lo para ser chave natural de uma cidade, porque tem cidades que tem diversos ceps, analogamente não pode usar para estados, uma tabela de cep serve apenas como restrição se um cep é válido ou não e mesmo assim não serviria 100% já que um cep que é válido em um ano pode não ser válido no outro.. Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. Na prática, a teoria é outra coisa. -- Shander Lyrio ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Date: Fri, 14 Oct 2011 15:24:52 -0300 From: shan...@nucleo45.com.br To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Função Update or Insert O Cep não é uma entidade, nem chave natural de entidade alguma é apenas o atributo de um endereço. Primeiro, em cidades pequenas que tenham cep único, você não consegue dar um cep diferente para cada endereço, logo ele não identifica unicamente uma entidade endereço. Você também não pode usá-lo para ser chave natural de uma cidade, porque tem cidades que tem diversos ceps, analogamente não pode usar para estados, uma tabela de cep serve apenas como restrição se um cep é válido ou não e mesmo assim não serviria 100% já que um cep que é válido em um ano pode não ser válido no outro.. Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. O CEP como atributo de um endereço, tem um domínio, ou conjunto pré-definido de valores que é a relação de CEPs gerenciada pelos Correios, que tem uma estrutura definida em [1]. Se fosse modelar com base nessas informações, uma relação de CEPs poderia ser tanto um domínio como uma entidade (dúvida sobre ser realmente uma entidade - mas na prática iria virar uma tabela mesmo). Na prática, a teoria é outra coisa. Realmente. Trabalho aqui com o CD do Diretório Nacional de Endereços dos Correios, que tenho que importar periodicamente para a nossa base, e na prática essa suposta tabela de CEPs vira uma estrutura bem mais complexa... [1] http://www.correios.com.br/servicos/cep/cep_estrutura.cfm Atenciosamente, Marçal de Lima Hokama ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 14-10-2011 15:53, Marcal Hokama escreveu: Uma tabela de cep's é apenas uma tabela cheia de dados em que o atributo cep é único e não se repete. Nada mais, um cep não pode ser usado como suficiente chave natural para identificar nada. O CEP como atributo de um endereço, tem um domínio, ou conjunto pré-definido de valores que é a relação de CEPs gerenciada pelos Correios, que tem uma estrutura definida em [1]. Se fosse modelar com base nessas informações, uma relação de CEPs poderia ser tanto um domínio como uma entidade (dúvida sobre ser realmente uma entidade - mas na prática iria virar uma tabela mesmo). Se os cep's não mudassem todo o ano eu até concordaria em dizer conjunto pré-definido, mas mudam. O que é um cep hoje, podem ser 2 amanhã, então nem adianta um on update cascade. Vejamos a situação, o atributo cep do endereço do cliente é uma foreign key para uma relação de ceps. No próximo ano os correios decidiram que este cep não existe mais, e agora? considerar cep como entidade te criaria um grande problema, porque derrepente, seu cliente passa a não ter mais cep ou a não ter um cep válido, ah, você tem uma restrição de integridade... então vá lá falar para os correios que eles não podem extinguir um cep. O que faremos?? Caso recente, a cidade em que eu nasci São Mateus-ES, tinha cep único 2993, já faz alguns anos que ele foi todo dividido porque a cidade cresceu, consulte o cep nos correios.. não existe mais. Mas até hoje, se você colocar o cep 2993 as encomendas chegam na casa dos meus pais certinho. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 10 de outubro de 2011 16:10, Fabrízio de Royes Mello fabriziome...@gmail.com escreveu: Todavia, melhor resolver mesmo na sua aplicação. Na minha visão, tentar fazer UPDATE numa linha que não existe tem mesmo é que retornar erro. +1 (mas sei que cada caso é um caso) Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE. No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Função Update or Insert
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE. No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro. Pois é, e o código tem de capturar o NOT FOUND como qualquer outro erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o que fôr correto no caso. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13 de outubro de 2011 11:49, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE. No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro. Pois é, e o código tem de capturar o NOT FOUND como qualquer outro erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o que fôr correto no caso. Sintaxe do MERGE: MERGE INTO table_name USING table_reference ON (condition) WHEN MATCHED THEN UPDATE SET column1 = value1 [, column2 = value2 ...] WHEN NOT MATCHED THEN INSERT (column1 [, column2 ...]) VALUES (value1 [, value2 ... Fonte: http://en.wikipedia.org/wiki/Merge_%28SQL%29 -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Função Update or Insert
Em 12-10-2011 21:48, Tiago Adami escreveu: Ok, entendi. Mas isto só se aplica quando você está usando SEQUENCES em chaves primárias - possivelmente artificiais. Isto não funcionaria com chaves naturais, do tipo CHAR ou VARCHAR, por exemplo. Agora começo entender porque os arquitetos de software vivem reclamando quando recuso a criação de chaves artificiais (geralmente colunas com nome ID do tipo Integer) só porque fica mais fácil trabalhar com Hibernate :) Exato, para ter algo gerado automaticamente obviamente ele deveria seguir um padrão onde o banco de dados pudesse gerar por si só este valor. Caso contrário, não tem nem lógica enviar um insert para o servidor sem a chave primária. ORM não resolve todos os males do mundo, ele resolve a grande maioria deles, mas não todos. Para mim, insert, update e delete é 99% por conta do ORM porque é quase sempre a mesma coisa. -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 12-10-2011 22:10, Guimarães Faria Corcete DUTRA, Leandro escreveu: começo entender porque os arquitetos de software vivem reclamando quando recuso a criação de chaves artificiais (geralmente colunas com nome ID do tipo Integer) só porque fica mais fácil trabalhar com Hibernate :) Espero que eles entendam que é porque chave artificial não garante unicidade, e geralmente confiar nelas deixa a base de dados inconsistente. Examente por isto você pode sempre criar um índice unique na chave natural que você usaria e que acha que garante unicidade. Teria o mesmo efeito de garantir unicidade, e ainda facilitaria o uso do ORM. A que custo?? Um pouco mais de espaço utilizado em disco. Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi diversas discursões sobre isto aqui na lista e no final sempre chega-se a conclusão que encontrar uma chave natural que realmente seja única é tão difícil quando encontrar um gnomo no final do arco-íres. -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13-10-2011 11:49, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Alexsander Rosaalexsander.r...@gmail.com: Mas um UPDATE de uma linha que não existe não dá erro, apenas não faz nada pois não encontra nenhuma tupla que satisfaça a cláusula WHERE. No máximo retorna NOT FOUND numa procedure, mas não chega a dar erro. Pois é, e o código tem de capturar o NOT FOUND como qualquer outro erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o que fôr correto no caso. Mas aí você não se contraria quando disse que era melhor fazer tudo em uma única consulta? Desta forma ele faria sempre em duas, então quer dizer que com o ORM tudo seria mais eficiente, no mínimo igual. Né não? Eu já havia feito estas contas, mas não havia pensando na possibilidade de tratamento do notfound, mesmo assim o ORM é ainda é mais econômico. Gostei! Abraço, -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Examente por isto você pode sempre criar um índice unique na chave natural que você usaria e que acha que garante unicidade. Teria o mesmo efeito de garantir unicidade, e ainda facilitaria o uso do ORM. A que custo?? Um pouco mais de espaço utilizado em disco. Há outros custos. O cache fica mais sujo mais rápido, o modelo de dados fica mais opaco, a tentação de usar a chave artificial para todas as chaves estrangeiras aumenta e acaba‐se sendo forçado a fazer junções que seriam desnecessárias se as chaves estrangeiras fossem sobre as naturais. Sem contar que chaves naturais têm o potencial de satisfazer consultas com o índice implícito, sem precisar nem ir para a tabela; se a aplicação já usa as chaves naturais preferencialmente, isso tenderá a estar em memória também, com ganhos ainda melhores. Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi diversas discursões sobre isto aqui na lista e no final sempre chega-se a conclusão que encontrar uma chave natural que realmente seja única é tão difícil quando encontrar um gnomo no final do arco-íres. Não é verdade. Quem chega a essa conclusão é quem não entendeu o modelo de dados, e aí a modelagem e aplicação serão malfeitas, com as conseqüências de sempre para desempenho, documentação, consistência… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Em 13-10-2011 11:49, Guimarães Faria Corcete DUTRA, Leandro escreveu: Pois é, e o código tem de capturar o NOT FOUND como qualquer outro erro, e tratá-lo, seja abortando, convertendo num INSERT ou seja lá o que fôr correto no caso. Mas aí você não se contraria quando disse que era melhor fazer tudo em uma única consulta? Eu? Eu falei que não era para fazer consulta nenhuma, só executar a operação que se espera a mais comum primeiro, capturar eventuais erros (inclusive tupla não encontrada num caso, preexistente noutro) e então decidir se executa a outra. Desta forma ele faria sempre em duas Pelo contrário. Geralmente faz‐se apenas uma operação, em vez de obrigatoriamente uma consulta e mais uma operação. quer dizer que com o ORM tudo seria mais eficiente, no mínimo igual. Não. Porque ele afasta o desenvolvedor do SQL, impondo uma mentalidade imperativa em vez da declarativa nativa; e porque ele tem o estado da base replicado na aplicação, impondo custos adicionais. Eu já havia feito estas contas, mas não havia pensando na possibilidade de tratamento do notfound, mesmo assim o ORM é ainda é mais econômico. Isso seria absolutamente impossível. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Exato, para ter algo gerado automaticamente obviamente ele deveria seguir um padrão onde o banco de dados pudesse gerar por si só este valor. Caso contrário, não tem nem lógica enviar um insert para o servidor sem a chave primária. Se a inserção não tem chave candidata natural, a tabela é um saco, não uma relação. Se a chave candidata natural é a primária ou não, só vai fazer diferença de acordo com o contexto, não inerentemente. ORM não resolve todos os males do mundo, ele resolve a grande maioria deles, mas não todos. Para mim, insert, update e delete é 99% por conta do ORM porque é quase sempre a mesma coisa. Non sequitur. De qualquer maneira, ORM cria mais problemas que resolve. O problema é menos grave com ORMs relativamente bons como o SQL Alchemy, e mais com nojentos como o Hibernate, mas sempre existe. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13 de outubro de 2011 13:57, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Shander Lyrio shan...@nucleo45.com.br: ORM não resolve todos os males do mundo, ele resolve a grande maioria deles, mas não todos. Para mim, insert, update e delete é 99% por conta do ORM porque é quase sempre a mesma coisa. Non sequitur. De qualquer maneira, ORM cria mais problemas que resolve. O problema é menos grave com ORMs relativamente bons como o SQL Alchemy, e mais com nojentos como o Hibernate, mas sempre existe. Na minha opinião um ORM só é útil em telas de cadastro extensas, onde fica mais fácil preencher as propriedades de um objeto e depois simplesmente executar um Save() e deixar o OPF se virar pra ver se vai usar INSERT ou UPDATE, ou ainda quais propriedades vai precisar alterar e quais pode omitir, etc. OK, o OPF provavelmente vai dar um SELECT * FROM tabela WHERE chave = x e pegar a tupla inteira, mas numa tela de cadastro isto é razoável -- se a chave não for obrigatoriamente um ID serial artificial, evidentemente. Ainda acho mais fácil fazer um cadastro de cliente desta maneira do que montar um SQL dinamicamente, por exemplo. No entanto é preciso ter cuidado e usar o OPF apenas nas telas de cadastro. Não dá pra usar o OPF numa tela que mostra uma LISTA de objetos buscados com SELECT *, isto gera um tráfego imenso e desnecessário. Nestes casos sempre é melhor usar uma VIEW que retorna apenas o que vai aparecer na tela -- aliás esta é uma regra aqui na Rednaxel: somente popule listas com views e somente coloque nas views dados que efetivamente aparecem na tela. De resto, damos preferência para stored procedures que fazem coisas como emite_nota, baixa_estoque, etc. Com isso as regras de negócio ficam no BD e podem ser acessadas por aplicações standalone, console, web, mobile, etc de forma transparente. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Função Update or Insert
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: De resto, damos preferência para stored procedures que fazem coisas como emite_nota, baixa_estoque, etc. Com isso as regras de negócio ficam no BD e podem ser acessadas por aplicações standalone, console, web, mobile, etc de forma transparente. O dia que tivermos um sistema completo de restrições de integridade, incluindo o ASSERTION de que o Euler lembrou outro dia, chaves em visões c, não precisaremos de código procedural para termos as regras de negócio na base… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13-10-2011 13:48, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: Eu acredito que o meio termo é, quase sempre, a melhor saída. Já vi diversas discursões sobre isto aqui na lista e no final sempre chega-se a conclusão que encontrar uma chave natural que realmente seja única é tão difícil quando encontrar um gnomo no final do arco-íres. Não é verdade. Quem chega a essa conclusão é quem não entendeu o modelo de dados, e aí a modelagem e aplicação serão malfeitas, com as conseqüências de sempre para desempenho, documentação, consistência… Não, quem chega a esta conclusão é quem está vivendo o processo do desenvolvimento. Modelo relacional não explica tudo, tentar forçar tudo a se encaixar no modelo relacional é contraproducente. O que seria chave natural para um cadastro de clientes?? cpf se for física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é o caso de um colega do sul que presta serviço à escolas que se não me engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes. Estou quase convencido que não existe uma chave natural perfeita para este simples cadastro de clientes, que tal um sequenciamento genético? Hum não funcionaria em empresas!!! Sequenciamento genético com os donos?? A!!! E quando a empresa fosse S/A?? Poxa!!! Você já parou para pensar que quando algo vai para o cache do PostGreSql, a página de dados toda vai para o cache?? não são simplesmente os dados, mas toda a página, com todos os campos. Ela pode inclusive estar cheia de buracos de registros já apagados e atualizados que ainda não foram recuperados com um vacuum, um campo a mais indo para o cache vai impactar um pentelhésimo de segundo ou nada. Se estivermos falando do que está definido no effective_cache_size, o assunto é ainda mais complexo, porque apenas os campos selecionados vão para esta área da memória para as agregação, join, e etc. Pessoalmente acho que o melhor custo/benefício é trabalhar com o cache da aplicação, ele bem administrado vai reduzir drasticamente a quantidade de consultas enviadas para o banco de dados. Sempre tem um porém, sempre tem um más. Na prática a teoria é outra coisa! Ainda acho que o caminho é DBA e equipe de programação tentando trabalhar juntos, um tentando ajudar o outro no que for melhor para a aplicação e quando digo aplicação, digo sistema + banco de dados. Se eu economizo várias horas de programação da equipe eu tenho mais condições de barganhar um sistema de discos melhor, mais memória, mais processador. Sei que alguns colegas respondem como se fossem unicamente DBA's a conversar nesta lista, mas não são, tem caras, onde eu me encaixo, que estão apenas tentando tornar o gap que existe entre banco de dados e aplicação um pouquinho menor. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Shander Lyrio shan...@nucleo45.com.br: Não, quem chega a esta conclusão é quem está vivendo o processo do desenvolvimento. Modelo relacional não explica tudo, tentar forçar tudo a se encaixar no modelo relacional é contraproducente. Modelo não é e nunca foi explicação, é formalização. Se não pode ser formalizado, será inconsistente. O que seria chave natural para um cadastro de clientes?? cpf se for física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é o caso de um colega do sul que presta serviço à escolas que se não me engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes. Sim, e a conclusão sempre foi a mesma: em última instância, a chave natural pode vir a ser a tabela toda, excluídos atributos artificiais. Se nem isso identificar, então a base de dados será inconsistente. Estou quase convencido que não existe uma chave natural perfeita para este simples cadastro de clientes, que tal um sequenciamento genético? Hum não funcionaria em empresas!!! Sequenciamento genético com os donos?? A!!! E quando a empresa fosse S/A?? Poxa!!! Quem perde a calma perde a razão. Você já parou para pensar que quando algo vai para o cache do PostGreSql, a página de dados toda vai para o cache?? Por favor, o nome do sistema é PostgreSQL ou Postgres. não são simplesmente os dados, mas toda a página, com todos os campos. Ela pode inclusive estar cheia de buracos de registros já apagados e atualizados que ainda não foram recuperados com um vacuum, um campo a mais indo para o cache vai impactar um pentelhésimo de segundo ou nada. Se estivermos falando do que está definido no effective_cache_size, o assunto é ainda mais complexo, porque apenas os campos selecionados vão para esta área da memória para as agregação, join, e etc. E daí? Pessoalmente acho que o melhor custo/benefício é trabalhar com o cache da aplicação, ele bem administrado vai reduzir drasticamente a quantidade de consultas enviadas para o banco de dados. O seu achômetro pessoal vai contra a experiência geral da humanidade. O cache da aplicação tem seu lugar, mas ele não está tão próximo do disco quanto o da base. Sempre tem um porém, sempre tem um más. Na prática a teoria é outra coisa! Ainda acho que o caminho é DBA e equipe de programação tentando trabalhar juntos, um tentando ajudar o outro no que for melhor para a aplicação e quando digo aplicação, digo sistema + banco de dados. E, para isso, quem tem a visão geral dos dados é o AD, que pode ou não ser o DBA. Se eu economizo várias horas de programação da equipe eu tenho mais condições de barganhar um sistema de discos melhor, mais memória, mais processador. O que não adianta nada quando a aplicação não escala e a base é inconsistente. Sei que alguns colegas respondem como se fossem unicamente DBA's a conversar nesta lista, mas não são, tem caras, onde eu me encaixo, que estão apenas tentando tornar o gap que existe entre banco de dados e aplicação um pouquinho menor. E esses caras fariam bem em tentar aprender um pouco em vez de sempre reagir emocionalmente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Pessoalmente acho que o melhor custo/benefício é trabalhar com o cache da aplicação, ele bem administrado vai reduzir drasticamente a quantidade de consultas enviadas para o banco de dados. O seu achômetro pessoal vai contra a experiência geral da humanidade. O cache da aplicação tem seu lugar, mas ele não está tão próximo do disco quanto o da base. Qual seria a melhor localização dos dados? Próximo da aplicação, que é quem vai processar e gerar informação ou próximo da base que é quem vai guardar os dados? Pois para mim não adianta ficar lá na base tão bem guardados que nunca chegam ao cliente, se é que me entendem. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 13 de outubro de 2011 15:44, Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Shander Lyrio shan...@nucleo45.com.br: O que seria chave natural para um cadastro de clientes?? cpf se for física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é o caso de um colega do sul que presta serviço à escolas que se não me engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes. Sim, e a conclusão sempre foi a mesma: em última instância, a chave natural pode vir a ser a tabela toda, excluídos atributos artificiais. Se nem isso identificar, então a base de dados será inconsistente. Discordo do uso indiscriminado de chaves artificiais, isso traz mais malefícios do que benefícios. No entanto, na minha opinião o código do cliente não é uma chave artificial, pois ele aparece fora da aplicação. Nas nossas contas de luz, telefone, etc está impresso nosso número de cliente, por exemplo. Da mesma forma, o número do pedido também é relevante fora da aplicação, vem do tempo em que os comerciantes preenchiam à mão talões numerados mecanicamente (na gráfica). Essa é uma realidade que existe desde o início do século passado, temos que levar isto em consideração. -- Atenciosamente, Alexsander da Rosa http://rednaxel.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] Função Update or Insert
Em 13-10-2011 15:44, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/13 Shander Lyrioshan...@nucleo45.com.br: O que seria chave natural para um cadastro de clientes?? cpf se for física ou cnpj se for jurídica? existe alguma melhor? e quando a esposa e o marido usam o mesmo cpf ou cara é de fora do Brasil e seu documento chama-se passaporte? e quando várias empresas usarem o mesmo cnpj como é o caso de um colega do sul que presta serviço à escolas que se não me engano tem o mesmo cnpj? Isso já foi discutido aqui na lista diversas vezes. Sim, e a conclusão sempre foi a mesma: em última instância, a chave natural pode vir a ser a tabela toda, excluídos atributos artificiais. Se nem isso identificar, então a base de dados será inconsistente. Certo, num cadastro de clientes deveríamos colocar todos os campos como chave primária. É esta sua opinião? Porque se for, ela contraria as suas colocações anteriores de que se a chave fosse natural estaria em memória, seria mais rápido fazer consultas, etc, etc, etc.. Estou quase convencido que não existe uma chave natural perfeita para este simples cadastro de clientes, que tal um sequenciamento genético? Hum não funcionaria em empresas!!! Sequenciamento genético com os donos?? A!!! E quando a empresa fosse S/A?? Poxa!!! Quem perde a calma perde a razão. Não perdi a calma não, eu estou escrevendo este e-mail até rindo. Acho engraçado você defender tanto a teoria quando não consegue pela teoria se justificar com um fato real simples como esse. Você já parou para pensar que quando algo vai para o cache do PostGreSql, a página de dados toda vai para o cache?? Por favor, o nome do sistema é PostgreSQL ou Postgres. Você vive de teoria de banco de dados, um monte de falácia que quando confrontada com a realidade, não consegue se sustentar. Você sequer conseguiu explicar como ter uma chave natural fiável num simples cadastro de clientes, e tenta mudar o assunto chamando atenção para a forma que eu coloco a caixa alta ou baixa no meu texto? não são simplesmente os dados, mas toda a página, com todos os campos. Ela pode inclusive estar cheia de buracos de registros já apagados e atualizados que ainda não foram recuperados com um vacuum, um campo a mais indo para o cache vai impactar um pentelhésimo de segundo ou nada. Se estivermos falando do que está definido no effective_cache_size, o assunto é ainda mais complexo, porque apenas os campos selecionados vão para esta área da memória para as agregação, join, e etc. E daí? E daí que seu argumento de cache sujo por causa de uma chave artificial cai por terra, porque ele é muito mais do que sujo, antes mesmo de a chave artificial existir. Ou seja, o fato de a chave artificial sujar o cache é absolutamente irrelevante. Pessoalmente acho que o melhor custo/benefício é trabalhar com o cache da aplicação, ele bem administrado vai reduzir drasticamente a quantidade de consultas enviadas para o banco de dados. O seu achômetro pessoal vai contra a experiência geral da humanidade. O cache da aplicação tem seu lugar, mas ele não está tão próximo do disco quanto o da base. Você *acha* que a experiência geral da humanidade é esta. Eu estou falando de custo/benefício e não qual cache é melhor. O que você pode fazer de efetivo para melhorar o desempenho da aplicação com relação ao cache do banco de dados?? Nada ou bem próximo disso!! Aumentar o cache pode ser feito com ou sem ORM, então nem conta. Trabalhando em um cache de aplicação eu posso ser muito mais efetivo porque vou criar um ganho real para a aplicação e alivar a quantidade de consultas ao banco de dados, independente do ganho que o cache de banco de dados já me proporciona. Entendeu agora?? custo/benefício. Com relação ao cache de banco nada pode ser feito senão aumentar ou diminuir ele, na aplicação muito pode ser feito, por isso insisto no tema. Trabalhar junto! Desenvolvimento + Banco de dados para o sucesso do conjunto!! E, para isso, quem tem a visão geral dos dados é o AD, que pode ou não ser o DBA. Suas respostas estão sendo dadas como DBA ou como AD? De qualquer forma acredito que você esteja vendo a situação apenas de um ângulo. Se eu economizo várias horas de programação da equipe eu tenho mais condições de barganhar um sistema de discos melhor, mais memória, mais processador. O que não adianta nada quando a aplicação não escala e a base é inconsistente. Na prática a teoria é outra. Os bancos de dados mais escaláveis não tem nada de consistentes, nada de primary keys ou foreign keys, restrição de campos, unique, rigidez de estrutura das tabelas, etc. Vide vários noSql que estão por aí ganhando terreno onde escalabilidade é o fator importante. Na prática, um certo nível de inconsistência desde que controlado é facilmente absorvido. Sei que alguns colegas respondem como se
Re: [pgbr-geral] Função Update or Insert
2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: Discordo do uso indiscriminado de chaves artificiais, isso traz mais malefícios do que benefícios. No entanto, na minha opinião o código do cliente não é uma chave artificial, pois ele aparece fora da aplicação. Perfeitamente! E por isso mesmo pode‐se, e deve‐se sempre que possível, declarar mais de uma chave natural — não confundir com chave simples versus composta. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Alexandre, poderia citar os malefícios das chaves artificiais? Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org escreveu: 2011/10/13 Alexsander Rosa alexsander.r...@gmail.com: Discordo do uso indiscriminado de chaves artificiais, isso traz mais malefícios do que benefícios. No entanto, na minha opinião o código do cliente não é uma chave artificial, pois ele aparece fora da aplicação. Perfeitamente! E por isso mesmo pode‐se, e deve‐se sempre que possível, declarar mais de uma chave natural — não confundir com chave simples versus composta. ___ 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] Função Update or Insert
Em 10 de outubro de 2011 22:02, Shander Lyrio
shan...@nucleo45.com.br escreveu:
Em 10/10/2011 20:08, Tiago Adami escreveu:
Ok, mas imagine que há outra aplicação conectada ao banco de dados e
insere um registro. Como o aplicativo (persistência) saberá que o
objeto existe no banco, mas não na memória?
Isto é uma limitação da sua aplicação, linguagem, ou de sua escolha do
ORM.
Veja esta query que meu ORM SqlAlchemy gera e que eu postei em mensagem
imediatamente anterior:
insert into clientes(chaveprimaria, cliente)
values(nextval('chaveprimaria'), ?) returning chaveprimaria;
Não importa de onde venha a inclusão, nunca haverá repetição de chave
primária nem erro na inserção pois o próprio PostgreSql retornará um
inteiro com o valor da sequence utilizado para persistir o objeto.
Ok, entendi. Mas isto só se aplica quando você está usando SEQUENCES
em chaves primárias - possivelmente artificiais. Isto não funcionaria
com chaves naturais, do tipo CHAR ou VARCHAR, por exemplo. Agora
começo entender porque os arquitetos de software vivem reclamando
quando recuso a criação de chaves artificiais (geralmente colunas com
nome ID do tipo Integer) só porque fica mais fácil trabalhar com
Hibernate :)
Certa vez já tive que fazer _quase_ isso para simular o comando
MERGE de outro SGBD, e não tive outra opção a não ser criar um
programa que tentasse inserir, e no caso de violação da PK tratava o
erro em código fazia um UPDATE.
Merge de um SGDB? Qual SGDB faz merge e como funciona isso? Está
falando de juntar os dados de dois bancos de dados em um único? O que
isto tem haver com ORM?
MERGE do IBM DB2, que faz exatamente o que você quer. Assim como o
Osvaldo já mencionou em um post posterior, o Oracle também tem um. Só
faltou isso no Elefante... seria ótimo para ETL.
--
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] Função Update or Insert
2011/10/12 Tiago Adami adam...@gmail.com: começo entender porque os arquitetos de software vivem reclamando quando recuso a criação de chaves artificiais (geralmente colunas com nome ID do tipo Integer) só porque fica mais fácil trabalhar com Hibernate :) Espero que eles entendam que é porque chave artificial não garante unicidade, e geralmente confiar nelas deixa a base de dados inconsistente. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 10 de outubro de 2011 09:51, Jean Carlos Quaresma Mariano jeanquare...@gmail.com escreveu: Bom dia, gostaria de saber se o Postgres tem um o recurso Update or Insert? Não tem. Quando absolutamente necessário, algumas pessoas usam o mecanismo de gatilhos pra resolver isso. Todavia, melhor resolver mesmo na sua aplicação. Na minha visão, tentar fazer UPDATE numa linha que não existe tem mesmo é que retornar erro. []s Flavio Gurgel ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/10 Flavio Henrique Araque Gurgel fha...@gmail.com: tentar fazer UPDATE numa linha que não existe tem mesmo é que retornar erro. E a aplicação sempre pode capturar o erro para passar a inserir. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Não sei em que está sendo desenvolvida a aplicação, o que framework de persistência está sendo usado mas, essa funcionalidade, inclusive, já é implementada no Hibernate ( lado da aplicação ). Então pode ser utilizada a mesma lógica. Basicamente, o Hibernate verifica se já tem chave primária no objeto (tipo o id não nulo) a ser gravado na base, se não tiver Insert se tiver Update. Bruno E. A. Silva. Analista de Sistemas. 2011/10/10 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: 2011/10/10 Flavio Henrique Araque Gurgel fha...@gmail.com: tentar fazer UPDATE numa linha que não existe tem mesmo é que retornar erro. E a aplicação sempre pode capturar o erro para passar a inserir. ___ ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/10 Bruno Silva bemanuel...@gmail.com: Então pode ser utilizada a mesma lógica. Basicamente, o Hibernate verifica se já tem chave primária no objeto (tipo o id não nulo) a ser gravado na base, se não tiver Insert se tiver Update. Se isso for verdade, o Hibernate reproduz um mau padrão de programação. Não vale a pena selecionar toda a vez. Vale mais a pena tentar primeiro a operação mais comum, capturar o erro e passar para a alternativa. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Dutra, desculpa, não expliquei por completo. Como não sei se você tem conhecimento nessa parte e até pra ficar claro pra lista, no geral, vou tentar explicar sem usar os termos da programação em Hibernate. Ele não faz duas consultas. É que no caso de uma alteração de dados vc já trás todas as informações daquela tupla. Aí quando é passado pro Hibernate persistir/gravar, vão suas alterações no tupla, inclusive a chave primária. Aí ela estará preenchida e ele faz um update. Se você criou um registro a chave primária não está preenchida aí ele faz INSERT. Espero ter esclarecido. Se ficar dúvida, como não é o foco da lista, pode me mandar email direto. Bruno E. A. Silva. Analista de Sistemas. 2011/10/10 Guimarães Faria Corcete DUTRA, Leandro l...@dutras.org: Se isso for verdade, o Hibernate reproduz um mau padrão de programação. Não vale a pena selecionar toda a vez. Vale mais a pena tentar primeiro a operação mais comum, capturar o erro e passar para a alternativa. ___ 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] Função Update or Insert
Em 10/10/2011 14:59, Guimarães Faria Corcete DUTRA, Leandro escreveu: 2011/10/10 Bruno Silvabemanuel...@gmail.com: Então pode ser utilizada a mesma lógica. Basicamente, o Hibernate verifica se já tem chave primária no objeto (tipo o id não nulo) a ser gravado na base, se não tiver Insert se tiver Update. Se isso for verdade, o Hibernate reproduz um mau padrão de programação. Não vale a pena selecionar toda a vez. Vale mais a pena tentar primeiro a operação mais comum, capturar o erro e passar para a alternativa. Ele não seleciona, verifica no objeto que ainda está em memória, é apenas um: if (objeto.chaveprimaria == null) Isto ainda é feito apenas se o objeto estiver no estado *detached*, caso contrário, nem precisa fazer, já que se ele estiver no estado *managed* ele obviamente já deve estar com a chave primária atribuída. Abraço, -- Shander Lyrio http://about.me/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
2011/10/10 Shander Lyrio shan...@nucleo45.com.br: Ele não seleciona, verifica no objeto que ainda está em memória E se o objeto não estiver em memória? Colocando em outras palavras, fiquei com a impressão de que ele fará o pior possível, trará tudo em memória antes de fazer qualquer operação? Depois o SQL é que é lento… ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 10 de outubro de 2011 10:18, Flavio Henrique Araque Gurgel fha...@gmail.com escreveu: Bom dia, gostaria de saber se o Postgres tem um o recurso Update or Insert? Não tem. Quando absolutamente necessário, algumas pessoas usam o mecanismo de gatilhos pra resolver isso. Também podes utilizar RULES como mostrado em [1] (com algumas adaptações claro). Todavia, melhor resolver mesmo na sua aplicação. Na minha visão, tentar fazer UPDATE numa linha que não existe tem mesmo é que retornar erro. +1 (mas sei que cada caso é um caso) [1] http://www.depesz.com/index.php/2010/06/15/to-rule-or-not-to-rule-that-is-the-question/ -- 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] Função Update or Insert
Em 10/10/2011 15:34, Guimarães Faria Corcete DUTRA, Leandro escreveu:
2011/10/10 Shander Lyrioshan...@nucleo45.com.br:
Ele não seleciona, verifica no objeto que ainda está em memória
E se o objeto não estiver em memória?
Colocando em outras palavras, fiquei com a impressão de que ele fará o
pior possível, trará tudo em memória antes de fazer qualquer operação?
Depois o SQL é que é lento…
Sua impressão está errada. Um objeto criado em memória em Java é algo
como:
public class Cliente{
@id
private int chaveprimaria;
@Column
private String cliente;
... gets e sets...
}
Cliente joao = new Cliente();
Não há necessidade de consulta no banco de dados, o objeto está em
estado detached e portanto, quando for persistido (gravado no banco de
dados), o valor passado no campo chaveprimaria será
nextval('chaveprimeira'), algo como
insert into clientes(chaveprimaria, cliente)
values(nextval('chaveprimaria'), ?) returning chaveprimaria;
Se a consulta retornar ok, então o campo chaveprimaria do objeto é
atualizado e o objeto muda seu estado para managed.
Se, por outro lado, você populou um objeto baseado em uma busca no
banco de dados, então seu estado já é managed, portanto, não é
necessária verificação de chave primária preenchida ou não.
Este é o modo de funcionamento do SqlAlchemy (Python), acredito que
também seja a forma do EclipseLink e Hibernate (Java) que são
implementações da JPA do Java.
Um projeto com milhares de cabeças pensantes trabalhando e melhorando-o
por anos dificilmente vai se prestar a fazer as coisas da pior maneira
possível. ORM é apenas uma ferramenta, obviamente não serve para
qualquer tipo de trabalho, mas é uma ferramenta, que em muitos cenários
(eu diria maioria) tem grande utilidade, nós não deveríamos ser
alérgicos a ela.
Um detalhe importante: o SqlAlchemy utiliza returning se o banco de
dados utilizado tiver esta opção ou algo que se assemelhe, caso
contrário, vão primeiro gerar uma sequência, popular o objeto e depois
persistir.
Ao invés de rechaçar completamente os ORM's, acredito que deveríamos
auxiliá-los a trabalhar de forma melhor com os bancos de dados. Existem
DBA's que ajudaram na construção dos ORM's, não foram apenas
programadores, se temos condições de contribuir para que ele seja uma
ferramenta ainda melhor porquê não fazemos?
Para mim eles funcionam muito bem e muito rápido, e olha que eu tenho
muito mais experiência com o PostGreSql do que com ORM's. Se alguém
quiser contribuir com algum ORM neste sentido para que ele gere Sql's
cada vez melhores para o nosso PostgreSql, o código do dialeto para
PostGreSql do Hibernate está em [1] e o do SqlAlchemy está em [2].
[1] http://fwd4.me/0DSs
[2] http://fwd4.me/0DSu
Abraço,
--
Shander Lyrio
http://about.me/shander
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 10/10/2011 17:47, Shander Lyrio escreveu: Ele não seleciona, verifica no objeto que ainda está em memória E se o objeto não estiver em memória? Relendo, talvez eu não tenha respondido esta pergunta. Se o objeto foi criado pelo sistema, estando ou não persistido no banco de dados ele obrigatoriamente estará em memória. Qualquer variável manipulada por um programa deverá estar em memória. Só não estará se ainda não foi criado. Abraço, -- Shander Lyrio http://about.com/shander ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Função Update or Insert
Em 10 de outubro de 2011 17:52, Shander Lyrio shan...@nucleo45.com.br escreveu: Em 10/10/2011 17:47, Shander Lyrio escreveu: E se o objeto não estiver em memória? Relendo, talvez eu não tenha respondido esta pergunta. Se o objeto foi criado pelo sistema, estando ou não persistido no banco de dados ele obrigatoriamente estará em memória. Qualquer variável manipulada por um programa deverá estar em memória. Só não estará se ainda não foi criado. Ok, mas imagine que há outra aplicação conectada ao banco de dados e insere um registro. Como o aplicativo (persistência) saberá que o objeto existe no banco, mas não na memória? Certa vez já tive que fazer _quase_ isso para simular o comando MERGE de outro SGBD, e não tive outra opção a não ser criar um programa que tentasse inserir, e no caso de violação da PK tratava o erro em código fazia um UPDATE. -- 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] Função Update or Insert
Em 10/10/2011 20:08, Tiago Adami escreveu:
Ok, mas imagine que há outra aplicação conectada ao banco de dados e
insere um registro. Como o aplicativo (persistência) saberá que o
objeto existe no banco, mas não na memória?
Isto é uma limitação da sua aplicação, linguagem, ou de sua escolha do
ORM.
Veja esta query que meu ORM SqlAlchemy gera e que eu postei em mensagem
imediatamente anterior:
insert into clientes(chaveprimaria, cliente)
values(nextval('chaveprimaria'), ?) returning chaveprimaria;
Não importa de onde venha a inclusão, nunca haverá repetição de chave
primária nem erro na inserção pois o próprio PostgreSql retornará um
inteiro com o valor da sequence utilizado para persistir o objeto.
Certa vez já tive que fazer _quase_ isso para simular o comando
MERGE de outro SGBD, e não tive outra opção a não ser criar um
programa que tentasse inserir, e no caso de violação da PK tratava o
erro em código fazia um UPDATE.
Merge de um SGDB? Qual SGDB faz merge e como funciona isso? Está
falando de juntar os dados de dois bancos de dados em um único? O que
isto tem haver com ORM?
Abraço,
--
Shander Lyrio
http://about.me/shander
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
