[pgbr-geral] Res: Linguagens suportadas pelo post!
Agradeçido. De: Osvaldo Kussama osvaldo.kuss...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Quinta-feira, 4 de Março de 2010 17:46:35 Assunto: Re: [pgbr-geral] Linguagens suportadas pelo post! Em 4 de março de 2010 14:52, paulo matadr saddon...@yahoo.com.br escreveu: Pessoal, Venho com algo simples,vcs saberiam me dizer quais as linguagem suportadas pelo postgres 8.3? Dê uma olhada em: http://www.postgresql.org/docs/current/interactive/external-projects.html lá você terá informações tanto para clientes quanto para o servidor. Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.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] Usando CPF/CNPJ como PK
Em 4 de março de 2010 17:40, Leandro DUTRA leandro.gfc.du...@gmail.comescreveu: 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com: Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs. Mór di quê? Acho que as desvantagens superam as vantagens. -- Atenciosamente, Alexsander da Rosa Linux User #113925 Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude. -- Barry Goldwater ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 5 de março de 2010 09:30, Alexsander Rosa alexsander.r...@gmail.com escreveu: Em 4 de março de 2010 17:40, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com: Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs. Mór di quê? Acho que as desvantagens superam as vantagens. Em sua opinião quais seriam? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Atualizar todos campos tabela com dados de outra tabela
Estou tentando esse código $sql = UPDATE veiculo.modelo SET modelo = ( SELECT marca FROM veiculo.marca WHERE veiculo.marca.idmarca = veiculo.modelo.idmarca ) || ' ' ::varchar(2) || veiculo.modelo; mas recebo este erro: ERRO: faltando entrada para tabela veiculo na cláusula FROM LINE 2: ... = veiculo.modelo.idmarca ) || ' '::varchar(2) || veiculo.mo... ^ Eu quero que no select me retorne o campo marca da tabela veiculo.marca cujo o campo veiculo.marca.idmarca seja igual ao campo veiculo.modelo.idmarca corrente no update externo. Deu pra entender? -- View this message in context: http://old.nabble.com/Atualizar-todos-campos-tabela-com-dados-de-outra-tabela-tp27794225p27794225.html Sent from the PostgreSQL - Brasil mailing list archive at Nabble.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] Usando CPF/CNPJ como PK
Pra mim a única vantagem é poder gerar UUID fora do banco sem risco significativo de colisão. Aliás, o fato de não haver 100% de garantia de que não haverá JAMAIS uma colisão no longo prazo (imagine dezenas de anos em centenas de filiais com milhares de transações por segundo) é uma desvantagem. Qualquer probabilidade maior que 0% pode sempre acontecer -- e Murphy nos garante que VAI acontecer. E o pior: quando houver uma colisão, se o UUID não for UNIQUE ninguém ficará sabendo... Outras desvantagens: - dificulta o DEBUG (e eventuais auditorias), Imagine ativar o log_statement = mod e acompanhar o resultado. Imagine tentar rastrear o que um determinado usuário fez num dia e hora específicos olhando os SQL que ele gerou no período. Sabemos que pode-se modelar a auditoria, mas os negócios evoluem e o que se quer monitorar hoje é diferente do que se monitorava ontem. Arquivar o SQL é uma garantia de poder buscar coisas do passado, quando não se gravava a trilha de auditoria que se grava hoje. - ocupa BEM mais espaço em disco/memória que integer Uma UUID ocupa 128 bits. Um inteiro ocupa 32 bits. Em alguns casos pode-se usar até smallint, que ocupa 16 bits. Numa tabela que represente um relacionamento N x N com apenas duas colunas, pode-se ter um pulo de 4 (dois smallint) para 32 bytes (dois UUID) por tupla. Os índices também sofrem um impacto significativo. Nunca gostei do argumento memória é barata. - não pode ser usada em comunicação verbal. Imagine uma atendente de call center passando uma UUID para o cliente anotar como número da transação. Se eu tiver que usar uma sequence pra gerar este número da transação, o uso de UUID perde todo o sentido. Em 5 de março de 2010 10:17, Dickson S. Guedes lis...@guedesoft.netescreveu: Em 5 de março de 2010 09:30, Alexsander Rosa alexsander.r...@gmail.com escreveu: Em 4 de março de 2010 17:40, Leandro DUTRA leandro.gfc.du...@gmail.com escreveu: 2010/3/4 Alexsander Rosa alexsander.r...@gmail.com: Podem me chamar de ultrapassado, mas nunca simpatizei com UUIDs. Mór di quê? Acho que as desvantagens superam as vantagens. Em sua opinião quais seriam? -- Dickson S. Guedes mail/xmpp: gue...@guedesoft.net - skype: guediz http://guedesoft.net - http://www.postgresql.org.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -- Atenciosamente, Alexsander da Rosa Linux User #113925 Extremismo na defesa da liberdade não é defeito. Moderação na busca por justiça não é virtude. -- Barry Goldwater ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Atualizar todos campos tabela com dados de outra tabela
Em 5 de março de 2010 11:02, Bruno Carneiro guimaraescarne...@gmail.com escreveu: Estou tentando esse código $sql = UPDATE veiculo.modelo SET modelo = ( SELECT marca FROM veiculo.marca WHERE veiculo.marca.idmarca = veiculo.modelo.idmarca ) || ' ' ::varchar(2) || veiculo.modelo; mas recebo este erro: ERRO: faltando entrada para tabela veiculo na cláusula FROM LINE 2: ... = veiculo.modelo.idmarca ) || ' '::varchar(2) || veiculo.mo... ^ Eu quero que no select me retorne o campo marca da tabela veiculo.marca cujo o campo veiculo.marca.idmarca seja igual ao campo veiculo.modelo.idmarca corrente no update externo. Deu pra entender? Não. Pelo que entendi veiculo é seu schema, modelo, e marca são suas tabelas e na tabela modelo você tem um campo que também se chama modelo (idem para marca). É isso? Talvez seja mais claro se você informar a definição de suas tabelas. Osvaldo ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/5 Alexsander Rosa alexsander.r...@gmail.com: - não pode ser usada em comunicação verbal. Imagine uma atendente de call center passando uma UUID para o cliente anotar como número da transação. Se eu tiver que usar uma sequence pra gerar este número da transação, o uso de UUID perde todo o sentido. Detalhe: uma chave artificial, em princípio, torna-se natural quando chega ao usuário. Não precisa nem passar para o cliente: se a aplicação a usa na lógica, e a mostra para um operador como a atendente, já virou uma chave natural redundante com a chave natural preexistente. Idealmente, a aplicação nem a veria, mas creio não ser possível no SQL. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 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] Usando CPF/CNPJ como PK
Dickson, Em 4 de março de 2010 20:13, Mozart Hasse mozart.ha...@usa.net escreveu: Ah, questão de prática. -... cuidar dos malditos 40% sem PK artificial em bases muito menores. ... Mozart, apenas por curiosidade, essas chaves artificiais são sequences? Não, normalmente são apenas registros numerados pela aplicação via código ou triggers. Se sim, já aconteceu de você precisar copiar dados de outras bases para esta por exemplo? Se sim, pode nos expor como você o fez? Replicação. No caso de inserções em servidores distintos minha aplicação tem um esquema de alocação e distribuição automática de faixas de códigos entre eles, de forma que dois servidores nunca usam o mesmo código ao inserir dados em bases diferentes na mesma tabela. Quando a replicação não resolve, eu renumero os registros de uma das bases sem dó, incluindo todas as FKs dependentes da tabela principal. Não dá tanto trabalho assim, basta uns INSERT INTO SELECT bem escolhidos, como eu disse é questão de prática. Normalmente só precisamos renumerar alguma coisa na hora de exportar ou importar dados de sistemas externos. Não consigo lembrar de uma PK mal escolhida que nos tenha obrigado a renumerar alguma coisa por conta de migração ou conversão de dados. Já o abismo entre a perfeição conceitual de uma chave natural e o uso dela pela #(-)*%$#**$ do otimizador SQL não tem solução nem gambiarra que melhore. Atenciosamente Mozart Hasse ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/5 Mozart Hasse mozart.ha...@usa.net: Mozart, apenas por curiosidade, essas chaves artificiais são sequences? Não, normalmente são apenas registros numerados pela aplicação via código ou triggers. Ah, agora entendo porque tens tantos problemas. Já o abismo entre a perfeição conceitual de uma chave natural e o uso dela pela #(-)*%$#**$ do otimizador SQL não tem solução nem gambiarra que melhore. Na verdade há dois abismos: entre o modelo relacional e outros conceitos associados, como o próprio original de chave artificial, de um lado, e de outro o SQL; e entre as boas práticas de programação e os programas que geralmente se fazem. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 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] Erro ao instalar PostreSQL 8.4.2-1 no Windows Vista
Em 04/03/2010 21:07, vinicius perroni escreveu: Rapaz eu não me lembro acho que tive esse problema no win 7 também não sei se é o mesmo. Resolvi indo antes da instalação nos serviços e ativando o serviço Logon secundário como automático. Se tratando do janelão é bom reiniciar depois para dar sorte:) Vinicius Vinicius, valeu a dica, mas não rolou. O logon secundário já estava ativo antes da instalação. Mesmo porque, como se trata de uma estação de desenvolvimento, não há a necessidade desta forma de logon (em casa, para desenvolvimento Windows, uso o PG logando na conta local do sistema), pois com a conta postgres ele não iniciava (Windows XP SP3). []'s -- --- Att.: Willian Jhonnes L. dos Santos Analista/Desenvolvedor Object/Free Pascal willianjhon...@yahoo.com.br --- Seja livre. Use Linux. Grupo de Usuários GNU/Linux de São José dos Pinhais Linux user number 449753 --- Powered by Slackware Linux 13.0 Kernel 2.6.32.6-i686-core2quad --- ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] erro no postgre pode ocupar o banco a ponto de parar outras consultas.
Tenho um banco postgre 8.3, e venho tendo problema o mesmo serve um site, se o
banco para o site para, algo está ocorrendo no banco que esta parando os
serviços do site, achei as seguintes mensagens de erro antes do problema no log
STATEMENT: INSERT INTO conteudo da do insert
ERROR: invalid input syntax for type double precision:
STATEMENT: SELECT round(min(temperatura)) as min, round(max(temperatura)) as
max FROM temperatura where
previsao_idPrevisao=get_processamento_previsao('2010-03-05',1,1) and cidade =
'';
ERROR: invalid input syntax for integer:
muitos erros seguidos assim pode ocasionar uma parada no banco, ou o que pode
estar ocorrendo, porque se eu deixar o banco depois de um tempo volta sozinho,
mas reinicio o serviço pois não posso deixar o site parado por tanto tempo.
Me ajudem por favor.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
Em 05/03/2010 13:22, Leandro DUTRA escreveu: Já o abismo entre a perfeição conceitual de uma chave natural e o uso dela pela #(-)*%$#**$ do otimizador SQL não tem solução nem gambiarra que melhore. Na verdade há dois abismos: entre o modelo relacional e outros conceitos associados, como o próprio original de chave artificial, de um lado, e de outro o SQL; e entre as boas práticas de programação e os programas que geralmente se fazem. Não sei se é uma outra thread, mas eu gostaria de saber mais sobre chaver atificial, tipo quando é indicado para eu utilizar, assim pelo menos não utilizarei a torto e direito. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/5 Flávio Alves Granato digitaldr...@gmail.com: Não sei se é uma outra thread, mas eu gostaria de saber mais sobre chaver atificial, tipo quando é indicado para eu utilizar, assim pelo menos não utilizarei a torto e direito. Hm, vale um blogue. Para resumir, originalmente era para só o DBA ver chaves artificiais, no modelo físico. No modelo lógico, que deveria ser o único visível para usuários, aplicativos e ADs, apareceriam só as chaves naturais. Seria uma mera questão de desempenho; mesmo a pretensa complexidade das chaves compostas deveria ser abstraída pelas linguagens de programação, como aliás fazíamos em COBOL. Como o SQL não implementa chaves artificiais de verdade, até porque não separa o modelo lógico do físico, e como o suporte à abstração de chaves compostas é extremamente deficiente ou, até, inexistente em boa parte das linguagens de programação, acaba-se usando chave artificial quando a natural é composta de, digamos, mais de três atributos, conforme o gosto do freguês. Outro uso de chaves artificiais é quando nenhuma natural é estável, e o SGBD não suporta ON UPDATE CASCADE, mas eu, particularmente, prefiro alterações explícitas das chaves. Finalmente, há quem use chaves artificiais quando tem necessidades muito específicas de desempenho extremo, mas a maior parte das vezes elas impõem penalidades por aumentar os eventos de E/S ou por não garantirem unicidade. O que não se pode jamais fazer é definir apenas a chave artificial, e não a(s) natural(is). -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 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] Usando CPF/CNPJ como PK
Como o SQL não implementa chaves artificiais de verdade, até porque não separa o modelo lógico do físico, e como o suporte à abstração de chaves compostas é extremamente deficiente ou, até, inexistente em boa parte das linguagens de programação, acaba-se usando chave artificial quando a natural é composta de, digamos, mais de três atributos, conforme o gosto do freguês. uma boa implementação de chaves compostas pode ser um objeto, por exemplo, chamado idAlgumaCoisa contendo os atributos referentes à chave natural? Outro uso de chaves artificiais é quando nenhuma natural é estável, e o SGBD não suporta ON UPDATE CASCADE, mas eu, particularmente, prefiro alterações explícitas das chaves. o custo computacional de um ON UPDATE CASCADE vale o seu uso em tabelas gigantes? Concordamos que cpf e cnpj são boas chaves naturais candidatas mas e para o caso de uma tabela em que só tenha um atributo, como existe muito, uma tabela cargo relacionando com funcionário e nesta tabela cargo só se tem o nome do cargo. Minha pergunta é, seria melhor forçar o dono do sistema fazer uma codificação para cada cargo, tipo, A-1 : Gerente ou A-2 : Arquiteto ou mesmo utilizar a famigerada chave artificial? Neste último caso a chave artificial fica a cargo de uma sequence que fica a cargo do banco... e da preguiça do analista que implementar isso. Finalmente, há quem use chaves artificiais quando tem necessidades muito específicas de desempenho extremo, mas a maior parte das vezes elas impõem penalidades por aumentar os eventos de E/S ou por não garantirem unicidade. O que não se pode jamais fazer é definir apenas a chave artificial, e não a(s) natural(is). Com este comentário, acabo achando que a criação de códigos para uma chave natural para uma determinada tabela como exemplo a tabela cargo acima é válido. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Usando CPF/CNPJ como PK
2010/3/5 Flávio Alves Granato digitaldr...@gmail.com: uma boa implementação de chaves compostas pode ser um objeto, por exemplo, chamado idAlgumaCoisa contendo os atributos referentes à chave natural? Por aí, é como se faz em COBOL. o custo computacional de um ON UPDATE CASCADE vale o seu uso em tabelas gigantes? Qual custo? Afinal, nenhuma chave é alterada constantemente. E esse custo amiúde é compensado por evitar junções devido ao uso de chaves artificiais, pela economia do índice associado, pelo ‘emagrecimento’ das tabelas… Concordamos que cpf e cnpj são boas chaves naturais candidatas Não necessariamente. mas e para o caso de uma tabela em que só tenha um atributo, como existe muito, uma tabela cargo relacionando com funcionário e nesta tabela cargo só se tem o nome do cargo. Minha pergunta é, seria melhor forçar o dono do sistema fazer uma codificação para cada cargo, tipo, A-1 : Gerente ou A-2 : Arquiteto Não entendi. Qual o problema do nome do cargo ser chave? Para quê esse código? O que não se pode jamais fazer é definir apenas a chave artificial, e não a(s) natural(is). Com este comentário, acabo achando que a criação de códigos para uma chave natural para uma determinada tabela como exemplo a tabela cargo acima é válido. Não entendi mesmo. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 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
