Re: [pgbr-geral] Qual estrutura utilizar?
2009/12/29 Marcal Hokama mhok...@hotmail.com: haverá uma demanda de processamento (envolvendo CPU, memória e E/S), até por outra informação dada: porém quando inicia a execução das classificações o desempenho do servidor cai drasticamente. Há muitos fatores a considerar, ainda… os algoritmos são eficientes? O momento dos cálculos é conveniente? Que outras formas de os fazer haveria? Qual o gargalo, E/S ou processador? E vai por aí afora. é bem provável que o modelo atual (transacional) nao atenderá a essa necessidade de emissão de relatórios em tempo real, sendo necessária a criação de novas estruturas para atender a essa finalidade. Uma coisa não exclui a outra. Novas estruturas não significam que o modelo atual não atende; é tudo questão de modelo físico e circunstâncias. Tudo depende do contexto em que vai ser aplicado. Existem soluções que não são adequadas para determinados casos e para outros são. CQD. -- 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 Sent from Sao Paulo, SP, Brazil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de Campos Padrões
Leandro DUTRA escreveu: 2009/12/29 fabi...@wolaksistemas.com.br: 2009/12/29 fabi...@wolaksistemas.com.br: 2009/12/29  lis...@softpira.com: ) WITH ( OIDS=TRUE); Porque não tem utilidade, engorda a base e ainda possibilita erros de rpogramação. Não é o nosso caso, usamos os OIDS para algumas coisas internas como posicionamento de cursores, melhor que criar uma estrutura só para controlar isso. Pelo contrário… OIDs podem alterarem-se com restauração de cópias de segurança, podem ciclar… melhor criar algo que esteja no modelo, se for uma necessidade real. OIDs são resquício da tentativa (fracassada) de se fazer um SGBD SQL-OO. --- Sei disso. Mas não é o tipo de uso que você esta imaginando. sempre li que é para evitar chaves naturais como pk. Por quê? Pelo contrário, uma chave artificial não evita duplicidade, engorda a base e dificulta o entendimento do modelo. --- Não evita duplicidade? Me de um exemplo ou um case por favor, porque então a documentação está errada e tudo o que li tb. Uma chave natural por exemplo CPF, nada te garante que no futuro não irá mudar o padrão e ali o teu modelo foi pro saco. Usar uma chave artificial te livra de um monte de dor de cabeça Por exemplo? Pelo contrário, usar chaves artificiais, a médio prazo, gera muita dor de cabeça porque engorda a base (geralmente) e obscurece o modelo (sempre). Muitas vezes, nem se definem boas chaves naturais porque se usou o quebra-galho da artificial. --- Exemplos pf, engorda a base? Pelo que entendo facilita até a maneira que o banco trabalha. Obscurece o modelo? Por favor seja mais específico. Bah daí concordo contigo! O nome poderia ser outro, mas essa é uma daquelas coisas que acabam ficando pra trás, no nosso caso é uma UK tanto no nome como na função hehe! O tipo da alteração que pode valer a pena, embora possa ser meio traumática. --- Como hj estamos envolvidos com outros módulos do sistema já não vale a pena ficar mudando apenas para ficar "bonito e no padrão". Bom daí já discordo um pouco. Pra mim base e modelo que precisam ser alterados no meio do caminho é igual a sistema mal feito e mal projetado. A curto prazo, sim. A longo, não. Até agora estão se mostrando excelentes, tomara que continuem assim. As vezes a teoria é uma coisa, mas na prática é outra! Não vão continuar, são típicas decisões sem fundamento teórico nem, a longo prazo, prático. Regras criadas por desenvolvedores que nem entendiam dados, nem tiveram de dar manutenção em sistemas evoluídos ao longo do tempo. Algumas até generalizações incorretas de situações específicas. --- Essa afirmação é bem contundente, mas como esse sistema já está a 3 anos rodando no primeiro cliente (indústria com faturamento médio de 5 milhões mensais) acredito que já estamos no meio do caminho e se o modelo se mostrou eficiente até agora, duvido que vou ter problemas daqui pra frente, de qualquer forma vou guardar esse email e daqui a alguns anos tiramos a prova. Citando um trecho de uma palestra do Telles: "- Uma pessoa sem bom senso não se preocupa com melhores práticas - Uma pessoa com bom senso e pouca experiência procura aprender e utilizar as melhores práticas - Uma pessoa com bom senso e muita experiência sabe quando não utilizar as melhores práticas" Abração, Fabiano Machado Dias ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de Campos Padrões
Configure teu cliente para as respostas padrão, por favor… RFC 1855. 2009/12/30 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br: Sei disso. Mas não é o tipo de uso que você esta imaginando. Não estou imaginando, é que não há mais usos legítimos para OIDs. Não evita duplicidade? Me de um exemplo ou um case por favor, porque então a documentação está errada e tudo o que li tb. Sim, escreve-se muita bobagem. Por exemplo, imagine um cadastro qualquer, com um código incremental e um nome que tem de ser único. É um exemplo simplérrimo, só para mostrar o problema. 1 José 2 José 3 José Pronto, como foi que a chave artificial evitou duplicidade? Nesse exemplo, precisaria agregar à chave natural outras informações, como data de nascimento, filiação c. Uma chave natural por exemplo CPF, nada te garante que no futuro não irá mudar o padrão e ali o teu modelo foi pro saco. E qual o problema? ON UPDATE CASCADE e DEFERRABLE INITIALLY DEFERRED resolvem o problema, e este último até se adequa melhor ao modelo relacional. Particularmente, prefiro saber quando muda uma chave. Melhor que as alterações sejam explícitas que implícitas. Os problemas do CNPF são outros, geralmente: gente que não tem CNPF pode até ter conta bancária, por exemplo mulheres casadas com conta conjunta com o marido. Exemplos pf, engorda a base? Pelo que entendo facilita até a maneira que o banco trabalha. Em alguns casos, já citados, sim, por limitações do SQL. Mas na maioria dos casos é um atributo e um índice a mais sem necessidade, e mais junções. Obscurece o modelo? Por favor seja mais específico. Quem lê um modelo com chaves naturais entende tudo; quem lê um modelo com chaves artificiais tem de adivinhar muita coisa. Como hj estamos envolvidos com outros módulos do sistema já não vale a pena ficar mudando apenas para ficar bonito e no padrão. Eu diria que é para evitar ser amaldiçoado por todas as gerações futuras de usuários, programadores e analistas, sem falar nos DBAs. Essa afirmação é bem contundente, mas como esse sistema já está a 3 anos rodando no primeiro cliente (indústria com faturamento médio de 5 milhões mensais) acredito que já estamos no meio do caminho e se o modelo se mostrou eficiente até agora, duvido que vou ter problemas daqui pra frente, de qualquer forma vou guardar esse email e daqui a alguns anos tiramos a prova. Claro! Mas eu tenho o pressentimento de que, como está, teu sistema dificilmente crescerá muito, e continuará a ser mantido por ti, então nada do que falei se tornará visível. Na verdade, mesmo os grandes ERPs têm péssimos modelos. Até o catálogo da Oracle é mal modelado. Dá para ir tocando, mas são custos ocultos. Alguém os estimou globalmente em US$1,2T por ano. - Uma pessoa sem bom senso não se preocupa com melhores práticas - Uma pessoa com bom senso e pouca experiência procura aprender e utilizar as melhores práticas - Uma pessoa com bom senso e muita experiência sabe quando não utilizar as melhores práticas Exato. Porque ele estava se referindo a essas ‘melhores práticas’ falsas, como as que você usou. -- 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 Sent from Sao Paulo, SP, Brazil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Membro novo
Amigos, Estou com dificuldades para importar um BD MS Access para Postgres por conta da autonumeração. Já li algumas sugestões, consegui importar mas ao abrir dá uma mensagem como se o BD não estivesse OK. Tentei checar o código do erro e não encontrei no manual. Fazendo o mesmo com o MySQL é uma moleza, sem problemas. Atenciosamente, George 2009/12/29 Osvaldo Kussama osvaldo.kuss...@gmail.com 2009/12/29 George M Tabatinga george.tabati...@gmail.com: Senhores, Gostaria de utilizar a lista para melhor conhecer a ferramenta de BD Postgres. O PostgreSQL possui um excelente manual: http://www.postgresql.org/docs/current/interactive/index.html Sempre que você tiver alguma dúvida pode recorrer ao wiki [1], ao histórico da lista [2] e, caso sua dúvida ainda não tenha sido sanada, posta-la aqui que a comunidade se prontificará a respondê-la. Não se esqueça também de seguir as regras da netiqueta [3]. Osvaldo [1] http://wiki.postgresql.org/wiki/Main_Page [2] http://listas.postgresql.org.br/pipermail/pgbr-geral/ [3] http://pt.wikipedia.org/wiki/Netiqueta ___ 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] Erro update
Caros, Estou com um problema que não consigo descobrir. Tenho uma estrutura de banners, que assim que o sistema (em java) retorna o banner, eu executo um update no campo de views para contabilizar +1. Porém, de tempos em tempos estou recebendo o seguinte erro: ERROR: could not open segment 1 of relation 1663/212219/215359 (target block 985008): No such file or directory Reindexando a tabela de banners, resolve o problema, mas preciso saber exatamente o que pode ser para que não ocorra novamente. A versão do postgresql é 8.1.18 Só um detalhe: eu rodava o mesmo sistema em outro server sem nenhum problema. A versão do postgre neste caso era 8.1.9. Alexandre Biancuzzi mailto:alexan...@lexxis.com.br alexan...@lexxis.com.br http://www.lexxis.com.br +55 (16) 9145-1234 +55 (16) 3011-7108 image001.jpg___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Membro novo
2009/12/30 George M Tabatinga george.tabati...@gmail.com: Estou com dificuldades para importar um BD MS Access para Postgres por conta da autonumeração. Qual o problema exatamente? Já li algumas sugestões, consegui importar mas ao abrir dá uma mensagem como se o BD não estivesse OK. Abrir o quê, como? Tentei checar o código do erro e não encontrei no manual. Que código, em que operação, em que componente? Fazendo o mesmo com o MySQL é uma moleza, sem problemas. Sim, ele reproduz alguns erros do MS Access. -- 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 Sent from Sao Paulo, SP, Brazil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Lista (Era: Membro novo)
Por favor, nunca reaproveite mensagem antiga e, se o assunto mudar, mude a linha de assunto. E desculpe não ter alterado, na minha resposta. 2009/12/30 George M Tabatinga george.tabati...@gmail.com: Amigos, -- 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 Sent from Sao Paulo, SP, Brazil ___ 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 update
2009/12/30 [Lexxis] Alexandre Biancuzzi alexan...@lexxis.com.br ERROR: could not open segment 1 of relation 1663/212219/215359 (target block 985008): No such file or directory Erro físico de sistema de arquivos. Reindexando a tabela de banners, resolve o problema Porque aí não volta a usar o mesmo bloco. A versão do postgresql é 8.1.18 Atualiza. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brazil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de Campos Padrões
2009/12/30 Andre Fernandes fernandes.an...@gmail.com: Desculpa-me entrar nesta discussão, contudo neste exemplo mencionado há um possível erro de modelagem, o problema não é a chave artificial explicitamente. Como eu disse, é um exemplo simplérrimo, somente para demonstrar o problema, a saber que chave artificial não garante unicidade. Chaves artificiais não são um mal por si só Na forma como implementadas hoje, são. Originalmente, eram uma idéia interessante, mas creio que não foram implementadas em nenhum sistema. Infelizmente, são um mal necessário em algumas situações. Mas somente complementando as naturais, nunca substituindo. Concordo que chaves artificiais podem ser problema quando o modelo está errado Não apenas, podem ser problemas físicos também. nem sempre chaves naturais são adequadas ou mesmo possuem bom desempenho Sempre são adequadas e sempre possuem bom desempenho — a não ser em situações bem específicas, como já descritas. (imagine uma chave composta onde todos os campos são strings, pode ser muito ruim para um bom desempenho de consultas). Mito. Além do mais, um id interno para o usuário, para a empresa, etc., pode ser facilmente entendido, não é um monstro que complica tudo. Mas obscurece quais as chaves verdadeiras. Geralmente, dificulta o entendimento. (lembre-se que nem as regras de normalização sempre devem ser seguidas, há momentos em que precisamos ferir uma delas para que o desempenho não seja ínfimo). Mas isso por limitações do 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 Sent from Sao Paulo, SP, Brazil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] [RESOLVIDO] Alterando a codifica ção do banco
obrigadão pela dica.
;)
2009/12/29 Steve Howe h...@vitavoom.com
Hello all,
Galera,
Resolvido.
QryAux.Close;
QryAux.SQL.Text:='SET CLIENT_ENCODING TO '+QuotedStr('LATIN1')+' ;';
QryAux.Open;
Zeos usa a libpq, então o caminho é esse mesmo. Eu usaria algo como:
Connection.ExecuteDirect('set client encoding to ''latin-1''');
... que usa menos recursos e não precosa de um componente de query, mas não
fará diferença considerável.
--
Best Regards,
Steve Howe
http://www.vitavoom.com
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
--
Marcelo Moacir Florindo
Analista/Desenvolvedor
http://www.gestaotec.com.br
___
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 update
2009/12/30 Leandro DUTRA leandro.gfc.du...@gmail.com: 2009/12/30 [Lexxis] Alexandre Biancuzzi alexan...@lexxis.com.br ERROR: could not open segment 1 of relation 1663/212219/215359 (target block 985008): No such file or directory Erro físico de sistema de arquivos. Aproveitando a deixa: este erro está acontecendo muito nos clientes da empresa onde trabalho. Todos com servidores Windows (muitas vezes o cliente possui apenas uma máquina onde o software ERP está instalado e também é o servidor). Outro problema que também está acontecendo é abortar a conexão ao rodar um simples SELECT sobre uma tabela (algum registro danificado, que em alguns casos consegui eliminar). Já vi este problema em servidor linux, mas neste SO é mais raro acontecer. O quê poderia estar causando estes problemas? -- 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] Erro update
Olá, 2009/12/30 Tiago Adami adam...@gmail.com 2009/12/30 Leandro DUTRA leandro.gfc.du...@gmail.com: 2009/12/30 [Lexxis] Alexandre Biancuzzi alexan...@lexxis.com.br ERROR: could not open segment 1 of relation 1663/212219/215359 (target block 985008): No such file or directory Erro físico de sistema de arquivos. Aproveitando a deixa: este erro está acontecendo muito nos clientes da empresa onde trabalho. Todos com servidores Windows (muitas vezes o cliente possui apenas uma máquina onde o software ERP está instalado e também é o servidor). Outro problema que também está acontecendo é abortar a conexão ao rodar um simples SELECT sobre uma tabela (algum registro danificado, que em alguns casos consegui eliminar). Já vi este problema em servidor linux, mas neste SO é mais raro acontecer. O quê poderia estar causando estes problemas? Pode ser disco. Aconteceu alguma queda de energia ou algo do tipo? Reindexação resolveu? -- 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 []s -- JotaComm http://jotacomm.wordpress.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] Qual estrutura utilizar?
Leandro, Particularmente, prefiro saber quando muda uma chave. Melhor que as alterações sejam explícitas que implícitas. Quer saber quando a chave muda? Registre alterações via trigger numa tabela de histórico. Teu modelo não tem nenhuma obrigação de mudar por causa desse desejo. Os problemas do CNPF são outros, geralmente: gente que não tem CNPF pode até ter conta bancária, por exemplo mulheres casadas com conta conjunta com o marido. E isso pode mudar a qualquer momento quando os requisitos do seu sistema mudarem. Conheci sistemas que precisaram colocar até nome da mãe na chave alternativa da tabela de pessoas para evitar duplicidades. Que tal fazer isso na minha tabela de pessoas, com 47 filhas? Quer embutir essa tralha toda na chave primária e em todas as chaves estrangeiras por questão de purismo conceitual? Quando eu trocar o tamanho do campo vou ter de criar um script monstruoso que levará horas ao invés de 30 segundos digitando uma linha. Quando alguém digitar errado o nome do cara durante o cadastro e notar isso no mês seguinte, depois de lanças algumas dezenas de notas, devo deixar o cliente esperando a emissão de nota ficar parada porque o banco de dados precisa aplicar o cascade nas 47 filhas para o modelo não ser prejudicado? Na-na-ni-na-não. Exemplos pf, engorda a base? Pelo que entendo facilita até a maneira que o banco trabalha. Em alguns casos, já citados, sim, por limitações do SQL. Mas na maioria dos casos é um atributo e um índice a mais sem necessidade, e mais junções. Em TODOS os bancos de dados o tamanho do índice conta na decisão de usá-lo ou não, e uma chave serial de 2, 4 ou 8 bytes jamais será maior do que qualquer chave natural que se encontre para a mesma tabela. Portanto, usar chaves naturais para fazer FKs aumenta sim o tamanho dos índices e tem toda a chance de igualar ou piorar o desempenho. Obscurece o modelo? Por favor seja mais específico. Quem lê um modelo com chaves naturais entende tudo; quem lê um modelo com chaves artificiais tem de adivinhar muita coisa. Se quer ler e entender o modelo, use a representação conceitual (modelo lógico). Quando puser para funcionar, terá de lidar com o modelo *físíco*, com todas as tabelas, índices, chaves artificiais, índices, triggers, visões materializadas e qualquer outra coisa que sirva para deixar a aplicação com um desempenho decente. Eu diria que é para evitar ser amaldiçoado por todas as gerações futuras de usuários, programadores e analistas, sem falar nos DBAs. Estou pra conhecer um DBA que goste de rasgar SLAs com cláusulas de tempo de resposta mínimo e mande todo mundo parar de trabalhar para esperar o banco fazer um DELETE CASCADE numa tabela com mais de 10 registros. Estou também para conhecer um DBA que seja contratado por alguém que se dê ao luxo pagar um cara qualificado para dizer para o cliente senta e chora quando identificar deadlocks causados por purismos conceituais. Claro! Mas eu tenho o pressentimento de que, como está, teu sistema dificilmente crescerá muito, e continuará a ser mantido por ti, então nada do que falei se tornará visível. 3 anos é pouco pra você?! Tá bom, que tal o sistema que mantenho hoje, que tem uns 15? 900 tabelas tá bom pra você ou é meio pequenininho pra entrar na conta? Na verdade, mesmo os grandes ERPs têm péssimos modelos. Até o catálogo da Oracle é mal modelado. Catálogo do Oracle mal modelado? Quando apresentar algum mais normalizado que faça o mesmo que ele e ainda por cima tenha o mesmo desempenho, avise. Dá para ir tocando, mas são custos ocultos. Alguém os estimou globalmente em US$1,2T por ano. Isto é apenas um número sem fonte (vulgo chute) com um valor cheio de zeros. Chutes não vão convencer ninguém a mudar de idéia nem vão justificar qualquer abordagem que se apresente. especialmente se você quiser usar a chave para identificar alterações concorrentes sobre o mesmo registro Nível de isolamento serializável, e de quebra a aplicação fica mais robusta. E mais lenta, especialmente em acessos concorrentes. Nem todo mundo tem tempo, dinheiro ou motivo para esperar. Agora me dei conta? será que teus problemas recorrentes de desempenho não são por controle de transações na aplicação? Não, pois faço os testes de desempenho com uma única conexão a um servidor dedicado. A melhoria é grande demais para ser ignorada, pois quase todos os índices ficarão menores Ou melhor, depende. Tabela mãe pequena e pouco usada com tabelas filhas grandes, pode ser, se não forçar junções demais. Tamanho do índice entra na conta, especialmente com muitos registros tanto na tabela pai quanto na filha. Mas sempre haverá um índice a mais, tanto em disco quanto em memória, ocupando também cache e exigindo atualizações. O que só seria problema se a atividade mais frequente fosse atualizar as tabelas ao invés de consultá-las. e com distribuição estatística mais evidente (do ponto de vista do banco de dados)
Re: [pgbr-geral] Qual estrutura utilizar?
From: leandro.gfc.du...@gmail.com Date: Wed, 30 Dec 2009 07:40:50 -0200 To: pgbr-geral@listas.postgresql.org.br Subject: Re: [pgbr-geral] Qual estrutura utilizar? 2009/12/29 Marcal Hokama : haverá uma demanda de processamento (envolvendo CPU, memória e E/S), até por outra informação dada: porém quando inicia a execução das classificações o desempenho do servidor cai drasticamente. Há muitos fatores a considerar, ainda… os algoritmos são eficientes? O momento dos cálculos é conveniente? Que outras formas de os fazer haveria? Qual o gargalo, E/S ou processador? E vai por aí afora. Ok, ok... Vou voltar no tempo para tentar ajudar na dúvida original do Eder Sousa: Tenho um sistema de Distribuição onde 99% das atividades é inclusão de registros que por sua vez está incluido em um database, surgiu a necessidade de implantar um novo database onde será efetuado a carga de dados diárias com aproximadamente 50.000 registros dias, porém neste database será classificado N calculo para administrar o estoque de 55 filiais. Até a carga de dados funciona maravilhosamente, porém quando inicia a execução das classificações o desempenho do servidor cai drasticamente. Pergunto: Neste caso é necessário um novo servidor para executar os cálculos, ao invés de efetuar no mesmo servidor?? Só para conhecimento o servidor é um Quadcore com 8GB RAM e 1 Tera de HD []s Eder, eu diria que seria interessante neste caso saber algumas coisas: 1- O que você chama de classificações, o que faz exatamente? 2- De quanto em quanto tempo esta operação é executada? 3- Os dados gerados por estas classificações são armazenados em algum lugar? é bem provável que o modelo atual (transacional) nao atenderá a essa necessidade de emissão de relatórios em tempo real, sendo necessária a criação de novas estruturas para atender a essa finalidade. Uma coisa não exclui a outra. Novas estruturas não significam que o modelo atual não atende; é tudo questão de modelo físico e circunstâncias. Leandro, se eu tenho meu modelo de dados, e uma necessidade de uma determinada consulta que, utilizando as estruturas atuais, já foi otimizada ao máximo e o tempo decorrido não atende a necessidade do cliente, como vou dizer que esse modelo atual, sem ter nenhuma modificação, atende a minha necessidade? Marçal de Lima Hokama -- _ Faça transações bancárias de maneira segura. Baixe agora o Novo Internet Explorer 8. http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmailutm_medium=Taglineutm_content=Tag2utm_campaign=IE8 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Uso de Campos Padrões
Nesse exemplo você confundiu PK com UK. Mas vamos deixar pra lá! Leandro DUTRA escreveu: 2009/12/30 Andre Fernandes fernandes.an...@gmail.com: Desculpa-me entrar nesta discussão, contudo neste exemplo mencionado há um possível erro de modelagem, o problema não é a chave artificial explicitamente. Como eu disse, é um exemplo simplérrimo, somente para demonstrar o problema, a saber que chave artificial não garante unicidade. Chaves artificiais não são um mal por si só Na forma como implementadas hoje, são. Originalmente, eram uma idéia interessante, mas creio que não foram implementadas em nenhum sistema. Infelizmente, são um mal necessário em algumas situações. Mas somente complementando as naturais, nunca substituindo. Concordo que chaves artificiais podem ser problema quando o modelo está errado Não apenas, podem ser problemas físicos também. nem sempre chaves naturais são adequadas ou mesmo possuem bom desempenho Sempre são adequadas e sempre possuem bom desempenho — a não ser em situações bem específicas, como já descritas. (imagine uma chave composta onde todos os campos são strings, pode ser muito ruim para um bom desempenho de consultas). Mito. Além do mais, um id interno para o usuário, para a empresa, etc., pode ser facilmente entendido, não é um monstro que complica tudo. Mas obscurece quais as chaves verdadeiras. Geralmente, dificulta o entendimento. (lembre-se que nem as regras de normalização sempre devem ser seguidas, há momentos em que precisamos ferir uma delas para que o desempenho não seja ínfimo). Mas isso por limitações do 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] Uso de Campos Padrões
2009/12/30 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br: Nesse exemplo você confundiu PK com UK. Mas vamos deixar pra lá! Confundi não… não que fosse fazer diferença, conceitualmente são a mesma coisa. A diferença foi um excesso de cautela do Codd que o Date só corrigiu alguns anos depois, e o SQL agravou por causa dos NULLs. -- 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 Sent from Sao Paulo, SP, Brazil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Uso de Campos Padrões
Colega; mas podemos ter várias UK´s em uma tabela, e a PK é somente UMA, correto? E neste caso, o conceito é diferente! De: Leandro DUTRA leandro.gfc.du...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Quarta-feira, 30 de Dezembro de 2009 19:20:13 Assunto: Re: [pgbr-geral] Uso de Campos Padrões 2009/12/30 Wolak Sistemas - Fabiano Machado Dias fabi...@wolaksistemas.com.br: Nesse exemplo você confundiu PK com UK. Mas vamos deixar pra lá! Confundi não… não que fosse fazer diferença, conceitualmente são a mesma coisa. A diferença foi um excesso de cautela do Codd que o Date só corrigiu alguns anos depois, e o SQL agravou por causa dos NULLs. -- 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 Sent from Sao Paulo, SP, Brazil ___ 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] Erro update
2009/12/30 JotaComm jota.c...@gmail.com: Pode ser disco. Aconteceu alguma queda de energia ou algo do tipo? Reindexação resolveu? É difícil saber com exatidão se houve queda de energia. E a reindexação não têm ajudado muito. A realidade da empresa contém clientes com pouco ou quase nenhum conhecimento de informática ou equipamentos. Usam o sistema por obrigação mesmo (Emissão de Notas, Sintegra, essas coisas). O importante é que o disco e o SO não apresentam falhas, o problema fica restrito ao banco quando acontece. Com certeza foi algum problema no disco, durante a gravação das informações do banco (writeback, cache, logs, algo do gênero). Mas pergunta é: quais as causas que podem trazer estes problemas? Desligamento incorreto? Queda de energia? Falha física (este com certeza)? O que mais? Lembrando que a maioria dos clientes utilizam Windows XP como servidor de banco. Atualmente utiliza-se a versão 8.2. -- 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] Erro update
No meu caso é o SO é linux com o equipamento dentro do datacenter da locaweb, o que descarta a possibilidade de quedas de energia devido a estrutura deles. O reindex resolve momentaneamente. Até pensei em problema com os arquivos, mas como resolver? Apagar e recriar o banco? Eu já efetuei esse procedimento com as tabelas, mas voltou a dar o erro. Alexandre Biancuzzi alexan...@lexxis.com.br http://www.lexxis.com.br +55 (16) 9145-1234 +55 (16) 3011-7108 -Original Message- From: pgbr-geral-boun...@listas.postgresql.org.br [mailto:pgbr-geral-boun...@listas.postgresql.org.br] On Behalf Of Tiago Adami Sent: quarta-feira, 30 de dezembro de 2009 20:45 To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Erro update 2009/12/30 JotaComm jota.c...@gmail.com: Pode ser disco. Aconteceu alguma queda de energia ou algo do tipo? Reindexação resolveu? É difícil saber com exatidão se houve queda de energia. E a reindexação não têm ajudado muito. A realidade da empresa contém clientes com pouco ou quase nenhum conhecimento de informática ou equipamentos. Usam o sistema por obrigação mesmo (Emissão de Notas, Sintegra, essas coisas). O importante é que o disco e o SO não apresentam falhas, o problema fica restrito ao banco quando acontece. Com certeza foi algum problema no disco, durante a gravação das informações do banco (writeback, cache, logs, algo do gênero). Mas pergunta é: quais as causas que podem trazer estes problemas? Desligamento incorreto? Queda de energia? Falha física (este com certeza)? O que mais? Lembrando que a maioria dos clientes utilizam Windows XP como servidor de banco. Atualmente utiliza-se a versão 8.2. -- 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Res: Uso de Campos Padrões
2009/12/30 MARCIO CASTRO marciomouracas...@yahoo.com.br: Colega; mas podemos ter várias UK´s em uma tabela, e a PK é somente UMA, correto? Sim. Mas isso é uma definição do ISO SQL sem fundamento conceitual. Vide que primária, no caso, quer dizer apenas que foi definida como tal, e ‘única’ é redudante com ‘chave’. Mesmo a diferença de que a primária não pode aceitar NULLs é tão arbitrária, que em Oracle nem faz sentido, porque em Oracle '' IS NULL. E neste caso, o conceito é diferente! Não, porque é uma diferença arbitrária. Conceitualmente, qualquer chave candidata pode ser tanto a primária quanto uma alternativa. Na verdade, um sistema relacional nem deveria ter o conceito de chave primária, porque ele é arbitrário, aumenta a complexidade do sistema desnecessariamente, e acaba obscurecendo o próprio conceito de chave. Conheço gente que fez cursos que eu invejo que ainda não entendeu que uma chave pode ser composta… e que ainda confunde índice com chave. Até um certo SGBD cetáceo pseudo-SQL faz isso. -- 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 Sent from Sao Paulo, SP, Brazil ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Res: Res: Uso de Campos Padrões
Bom; então me desculpe. Já fazem uns 20 anos que eu fiz banco de dados, e os conceitos acabaram se perdendo... :-) De: Leandro DUTRA leandro.gfc.du...@gmail.com Para: Comunidade PostgreSQL Brasileira pgbr-geral@listas.postgresql.org.br Enviadas: Quarta-feira, 30 de Dezembro de 2009 21:12:46 Assunto: Re: [pgbr-geral] Res: Uso de Campos Padrões 2009/12/30 MARCIO CASTRO marciomouracas...@yahoo.com.br: Colega; mas podemos ter várias UK´s em uma tabela, e a PK é somente UMA, correto? Sim. Mas isso é uma definição do ISO SQL sem fundamento conceitual. Vide que primária, no caso, quer dizer apenas que foi definida como tal, e ‘única’ é redudante com ‘chave’. Mesmo a diferença de que a primária não pode aceitar NULLs é tão arbitrária, que em Oracle nem faz sentido, porque em Oracle '' IS NULL. E neste caso, o conceito é diferente! Não, porque é uma diferença arbitrária. Conceitualmente, qualquer chave candidata pode ser tanto a primária quanto uma alternativa. Na verdade, um sistema relacional nem deveria ter o conceito de chave primária, porque ele é arbitrário, aumenta a complexidade do sistema desnecessariamente, e acaba obscurecendo o próprio conceito de chave. Conheço gente que fez cursos que eu invejo que ainda não entendeu que uma chave pode ser composta… e que ainda confunde índice com chave. Até um certo SGBD cetáceo pseudo-SQL faz isso. -- 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 Sent from Sao Paulo, SP, Brazil ___ 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] Res: Uso de Campos Padrões
Para facilitar o entendimento da diferença entre PK e UK, geralmente falamos A PK é uma UK com NOT NULL, e sobre o assunto achei o seguinte link: http://en.wikipedia.org/wiki/Unique_key Mas conceitualmente, se uma UK aceita valores nulos, nem poderíamos considerá-la como chave candidata, não? Marçal de Lima Hokama - Date: Wed, 30 Dec 2009 14:18:52 -0800 From: marciomouracas...@yahoo.com.br To: pgbr-geral@listas.postgresql.org.br Subject: [pgbr-geral] Res: Uso de Campos Padrões Colega; mas podemos ter várias UK´s em uma tabela, e a PK é somente UMA, correto? E neste caso, o conceito é diferente! De: Leandro DUTRA Para: Comunidade PostgreSQL Brasileira Enviadas: Quarta-feira, 30 de Dezembro de 2009 19:20:13 Assunto: Re: [pgbr-geral] Uso de Campos Padrões 2009/12/30 Wolak Sistemas - Fabiano Machado Dias : Nesse exemplo você confundiu PK com UK. Mas vamos deixar pra lá! Confundi não… não que fosse fazer diferença, conceitualmente são a mesma coisa. A diferença foi um excesso de cautela do Codd que o Date só corrigiu alguns anos depois, e o SQL agravou por causa dos NULLs. -- skype:leandro.gfc.dutra?chat Yahoo!: ymsgr:sendIM?lgcdutra +55 (11) 3854 7191 gTalk: xmpp:leand...@jabber.org +55 (11) 9406 7191 ICQ/AIM: aim:GoIM?screenname=61287803 BRAZIL GMT-3 MSN: msnim:chat?contact=lean...@dutra.fastmail.fm Sent from Sao Paulo, SP, Brazil ___ 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: Top 10 - Celebridades - Música - Esportes _ Navegue com segurança com o Novo Internet Explorer 8. Baixe agora, é gratis! http://brasil.microsoft.com.br/IE8/mergulhe/?utm_source=MSN%3BHotmailutm_medium=Taglineutm_content=Tag4utm_campaign=IE8 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
