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
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
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
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ã
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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, é
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
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
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
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
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,
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
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 é
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
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
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
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
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
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
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
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
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
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
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
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
40 matches
Mail list logo
