Hum... talvez seja esse meu ponto (positivo ou negativo? depende) , por eu não ter tempo e um DBA pra me ajudar a criar funcoes direto no banco eu faço todas ou a grande maioria das verificacoes direto nos meus aplicativos... por isso não tenho problemas com erros internos do MySQL. Quanto a data sabe que eu não tinha visto isso, pois normalmente eu peço que um campo data seja Not Null e na minha aplicação ele grita dizendo que o campo é necessario ou Null e ele sempre grava como Null mesmo, nao uso um valor por default em campo data, mas por curiosidade vou verificar esse lance da data.
From: C Grillo Sent: Friday, February 11, 2011 1:18 PM To: Marcelo Silva (IG) ; Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Novo no Grupo Prezado Marcelo: "Minha intenção não é confrontar MySQL x Postgres como muitos fazem... eu convivo com os dois sem problemas" Já eu convivo com MySQL desde 2003, mas com problemas...,não de performance nem de estabilidade, mas tem coisas que são absurdas no 'projeto' do MySQL. Por exemplo, a data 'zero de zero de mil novecento e zero' 0000-00-00: isto não existe, é um valor errado para um tipo de dado data, pois não existe mês zero ou dia zero. E ainda é o default do sistema quando cria um campo deste tipo. Outro exemplo grotesco: em uma stored procedure não tem-se acesso às varáveis de erro SQLSTATE, SQLCODE ou errno: tu tens que adivinhar o que pode acontecer e declarar como uma situação de erro em tempo de programação. Não podes imprimir o SQLCODE se deu um erro que tu não previste. Backup online, só págo. Os locks são tratados em diferentes níveis ( na camada MySQL mesmo e na camada InnoDB). Aliás, as chamadas 'storage engines' são, na minha opnião, uma solução de contorno para o fato de a empresa original do MySQL nunca ter implementado de fato um sistema transacional. E por aí vai. Agora, o MySQL no que faz é bom , estável e rápido. E fácil de usar. É bem programado. Mas o projeto, como um todo, não é o mais elegante e esperto em termos de Sistemas De Gerenciamento de Banco de Dados. Se tu usas MySQL, vais ter que conviver com suas limitações conceituais. É minha opnião pessoal.... Obrigado. Em 11 de fevereiro de 2011 09:27, Marcelo Silva (IG) <[email protected]> escreveu: De fato, existem muitas e muitas variáveis, seja em qualquer opção de migração, por isso deve-se ponderar o custo benefício. Se o problema é performance e o servidor carece de memoria, é mais fácil e mais barato comprar um pente de memoria do que reescrever toda sua aplicação e depois ver que ainda vai precisar de memoria. Agora se achar que deve trocar de base por N motivos, simplesmente troque, pois tanto o MySQL como Postgres são gerenciadores robustos (claro cada uma com sua particularidade). Então Roberto, só comentando... é questão de necessidade mesmo... hoje o que eu faço em termos de aplicações, apesar de trabalhar com milhões de registros, até tabelas DBFs com ADS eu conseguiria trabalhar, pois os hardwares estão melhores e a corrupção de dados é muito menor hoje (pelo menos já faz anos que não sei o que é uma base corrompida). Eu criei coragem de usar o Postgres porque o MySQL insistia em dar uma queda de conexão que não encontrava solução na web, foi só eu mudar do 5.0 para o 5.1 e resolveu, em questão de performance foi só rever os indices e colocar mais 1g de ram e deu certo. Eu já migrei sistemas de DBF para Firebird depois para MySQL e agora para Postgres... e em todos eles não existiram ferramentas mágicas, o mais confiável foi refazer tudo, pelo menos assim já pegava os bugs que passaram batidos e melhorei muitas funções, minhas aplicações são grandes mas nem tanto, mas existem situações que pra refazer tudo seria um caos. Estou gostando do postgres, realmente não conheço nem 1% do que ele é capaz, mas o que já conhece me serve pra fazer aplicações muito complexas e com grande volume de dados. Antes que nosso colega tenha um trabalhão com uma migração, é bom ele ponderar se é realmente necessário por suas necessidades, mas seja qual for a decisão dele, poderá usar o postgres em futuras aplicações que não irá se arrepender. Minha intenção não é confrontar MySQL x Postgres como muitos fazem... eu convivo com os dois sem problemas. From: Roberto Mello Sent: Thursday, February 10, 2011 11:31 PM To: Marcelo Silva (IG) ; Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Novo no Grupo 2011/2/10 Marcelo Silva (IG) <[email protected]> Num servidor que o MySQL estava ficando lento, bastou colocar mais 1G de memoria e o problema foi resolvido. Ou seja uma melhor analise das suas condições... trocar o MySQL pelo postgres por causa de performance nos dias de hoje, é trocar 6 por 1/2 duzia. Isso não é correto. O número de variáveis é enorme, e fazer uma afirmação tão pungente e ao mesmo tempo tão simplória não faz justiça às diferenças que existem de uma aplicação e uso para outro. Percebi que o Postgres se mostra um pouco, mas pouco, mais rapido, mas foram testes superficiais... não justifica todo o trabalho de uma migração, mas meu novos projetos estão todos em postgres. O PostgreSQL é mais lento em algumas situações, e extremamente mais rápido em outras. Mais escalonável e confiável em todas. Agora se for trocar por causa de alguma opção, como PL, pode até ser. Eu tenho preferido o Postgres por alguns fatores alheios, mais questão de gosto mesmo... gostei de trabalhar com o postgres, e ele me traz uma certa sensação de segurança. Se é só uma sensação é por que tá faltando um pouco de informação. Sucesso a todos. Roberto _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
