Que bom que foi de ajuda :-) Se precisar de mais alguma ajuda ou dica, é só deixar um post aqui que eu respondo.

De cara, me identifiquei com o trecho que diz “Uma tradição entre os profissionais de TI, que é importante ter em mente, é que os DBAs costumam ser as pessoas mais conservadoras da equipe”. Não à toa, não sou maluco de sair migrando tudo, mas aos poucos vou me familiarizando com o PostgreSQL. Valeu mais uma vez!

Respondendo as suas perguntas:

Sim! É tranquilo migrar para o PostgreSQL.

Sim! Dificilmente vai dar problema com esse banco! Uma base de dados bem feita em um PostgreSQL bem configurado não dá problema! O PostgreSQL é um banco de dados muito mais robusto (na minha opinião) que o MySQL. Aguenta muito mais o tranco! Se a sua base roda bem em MySQL, vai rodar tão bem ou melhor em PostgreSQL.

Existem várias páginas em português e inglês sobre o uso do PostgreSQL, além de listas de discussão. Porém, nada que um Google não resolva pra você ;-)

Mas de qualquer maneira, aqui vão alguns links úteis em português do Brasil:

– No próprio BR-Linux, uma coletânea de posts sobre PostgreSQL
– Lista de discussão do PostgreSQL no site oficial Brazuca.
– 10 Dicas para começar a usar o PostgreSQL – PostgreSQL Wiki
– PostgreSQL – Wikipédia, a enciclopédia livre
– Lista de discussão sobre PostgreSQL no Yahoo!

Para quem não tem problemas com Inglês, vai se deliciar com uma quantidade monstruosa de links úteis sobre o PostgreSQL (tanto para usuários de nível básico, intermediário, ou mesmo avançado). Muito úteis, por sinal (procurem no Google, é claro). E garanto que, com dedicação, vocês passarão de newbies para hackers em pouco tempo.

Espero ter ajudado. Qualquer outra dúvida, deixe recado nesse post. Pelo menos por mais uma semana estarei monitorando ele.

Não só quero incentivar aos “possíveis futuros” usuários órfãos do MySQL a criarem e manterem seu próprio fork, como quero incentivar os mesmos usuários a conhecerem uma alternativa SL/CA tão boa ou melhor que o MySQL — o PostgreSQL!

Um bom domingo para todos! ;-)

- é tranquilo migrar do MySQL?
- e principalmente: quando dá problema, é fácil achar a solução na documentação ou na internet?

São perguntas deste feliz usuário do MySQL que até o momento não viu necessidade de trocar para outro, seja PostgreSQL, Oracle ou o escambau. Mas dados os últimos acontecimentos, vejo que chegou a hora de dar uma espiadinha em outros bancos…

Na época eu tinha enviado o artigo como matéria para o Augusto, mas acredito que como o título está “Migrando de MySQL para Oracle”, não ajudou muito… Como eu disse, a motivação do artigo foi apenas tentar ajudar quem precisou fazer o mesmo que eu: ter um projeto rodando em MySQL e precisar rodar no Oracle.

Sobre a idéia dos tutoriais correlacionados, é ótima!

Sobre a “pronta utilização” do MySQL: já reparei, que no Windows, o pacote de instalação do PG 8.3 vem com um instalador muito amigável e um software de gerenciamento idem. Em todos estes anos, enquanto o PG foi ficando mais amigável, o MySQL foi adicionando características de um SGBD de “verdade”. Porém a fama ficou: MySQL é fácil de usar e “podre”; PG é robusto, porém “pé-de-vaca” e pra DBA.

E, por último, também concordo com você em outro ponto: a concorrência é ótima, e ver cada concorrente adotando o melhor do “adversário” é benéfico pra todos! :)

Mais uma vez obrigado pelas contribuições de vocês. :-)

@Weber Jr .:

Realmente concordo com seus extras. Eu realmente não sei o quão limitado o MySQL ainda continua com SQL puro, mas sei que o mesmo ainda possui alguma deficiência no assunto. Se pelo menos todos os bancos de dados SL/CA fossem 100% compatíveis (e estáveis) com SQL já seria um avanço e tanto. Isso possibilitaria que os desenvolvedores pudessem aprender sem medo SQL em profundidade, para que pudessem diminuir ao máximo a dificuldade de migração ou implementação de bancos de dados concorrentes com a “mesma base”.

E o desenvolvedor pode e muito se beneficiar disso. Além das atuais camadas (banco e web) ele pode começar a modularizar mais ainda seu projeto/software/aplicativo, criando subcamadas em cada um desses níveis. Principalmente na camada banco, que pode ser dividida em duas, ou até mesmo três sub-camadas, tudo para otimizar o projeto e facilitar (além de ajudar a modularizar) o desenvolvimento (e sub-divisão) da camada Web. A modularização de uma camada inferior sempre ajuda a camada superior. Um exemplo: uma vez que você cria novas sub-camadas no seu banco, você aumenta a liberdade de escolha por qual linguagem\ferramenta utilizar na camada superior. E ainda ajuda a diminiur o número de funções desnecessárias, grandes demais, e repetitivas, no desenvolvimento da camada superior.

E as atuais inovações da versão 8.3 do PostgreSQL (aliada as promessas de seu novo beta 8.4 do PostgreSQL) possibilitam a qualquer desenvolvedor Oracle, conhecer um equivalente de peso, e principalmente, de Código Aberto. Pra que gastar uma fortuna em um banco de dados proprietário se o PostgreSQL dá conta do recado com louvor?

@Carcará

Realmente, saber refinar sua instalação de PostgreSQL é um diferencial e tanto. Você mesmo pôde comprovar o quão mais rápido ficou esse banco em relação ao MySQL, só pelo refino das configurações.

E claro, nenhum banco de dados faz “mágica”. Ainda é preciso ser um bom desenvolvedor e se manter sempre atualizado, para saber manter e principalmente, desenvolver bons (e otimizados) bancos de dados.

@Rael

Realmente, o MySQL parece entregar para seus usuários um verdadeiro estado de “pronto pra uso”, diferente dos outros banco de dados SL/CA. Um dos motivos de pedir a contribuição de usuários MySQL é que eu queria utilizar a vivêrncia deles e suas informações precisas sobre o uso e facilidades de seu SGBD preferido, justamente para organizar e catalogar essas informações e oferecer feedback para outros projetos de banco de dados SL/CA (principalmente o PostgreSQL).

Acho que os projetos SL/CA relacionados tem de lutar juntos. As vantagens de cada projeto devem ser associadas e incorporadas pelos outros projetos. Isso ajuda também na aquisição da perfeita interoperabilidade entre os projetos. E é isso que ajuda e muito a aceitação e migração para projetos SL/CA. Eles não tem de ser somente “bons” ou “melhores” que seus concorrentes proprietários. Eles precisam ser inter-compatíveis ao máximo. Afinal, são dezenas de projetos SL/CA similares e, dentre eles, de dois a seis (apenas uma suposição) estariam no topo, dividindo os usuários de SL/CA. É nessa divisão que o SL/CA acaba perdendo, pois dilui a contra-onda em relação ao software proprietário equivalente.

NOTA: Quero deixar bem claro que sou completamente contra essa história de achar que só deveria existir um sistema operacional, um banco de dados, etc. É a pluraridade que dá força (e segurança) ao mundo SL/CA. Se eu pudesse listar um único item de restrição a esse movimento (sem fragilizá-lo) seria a obrigatoriedade de padronização básica e interoperabilidade completa. Acredito que isso não feriria nenhum projeto. Muito pelo contrário! Contribuiria para a criação de SL/CA cada vez mais profissionais, e prontos para a briga conjunta contra o software proprietário, não importando qual SL/CA relacionado você utiliza, e não haveria brigas sem sentido (também conhecidas erradamente como “Guerra Santa dos Softwares”) em “qual é o melhor”.

Quanto ao uso exclusivo de SQL, eu acredito que dei um passo a frente (ou atrás, depende do ponto de vista de cada profissional :-D ) e adotei a PLPGSQL (Linguagem Procedural pgsql: para quem ainda não conhece vale a pena investir nela em seus desenvolvimentos). E isso já tem alguns anos. Se eu pudesse definir a PLPGSQL em uma única palavra eu diria “Fantástica”. Você realmente faz miséria com seu banco de dados PostgreSQL com ela. A única desvantagem seria se o desenvolvedor realmente precisassem migrar seu banco de dados para algum SGBD concorrente. Mas em vista da capacidade atual do PostgreSQL acho impossível que uma mudança ocorra por falta de capacidade desse banco de dados. Acredito que o único caso provável seria uma intervenção da própria empresa, seja por questões comerciais de patrocínio (indo para um Oracle por exemplo, por questões de parceria, etc) ou (no pior caso) uma avaliação errada da administração de TI, indicando como opção um SGBD que não possui as devidas “capacidades” para o atual projeto.

E quanto ao seu site, sobre o tutorial de migração do MySQL para o Oracle, por que você não faz alguns tutorias correlacionados? Estamos discutindo SL/CA em um site que valoriza e apoia o uso, tanto de Linux quanto de softwares para Linux SL/CA. Por que não criar tutoriais de migração do Oracle para MySQL e do Oracle para PostgreSQL? Ah! E quando fizer isso, por que não divulga o link para seu site aqui no BR-Linux?

Um abraço a todos e continuem contribuindo com a discussão HALF-TOPIC proposta no caminhar dos comentários desse post: Quais as vantagens do MySQL que permitiram sua adoção ao invés de outros projetos de banco de dados SL/CA?

Boa noite a todos! :-)

Comecei a mexer com PHP em 2000. Na época, o PHP já vinha com suporte ao MySQL de fábrica. Eu não manjava de chaves estrangeiras, mas queria fazer um software bobo. Aprendi o básico de SQL, e pronto, tudo estava lá.

Nos anos que se seguiram, aprendi SQL mais profundamente, e comecei a brincar com outros bancos, inclusive Oracle (escrevi até um tutorial na minha página da migração do MySQL pro Oracle) e vi, o quanto de coisas que o MySQL não oferecia. Por outro lado, vi o quanto de trabalho que o Oracle dava, afinal, não é a toa que existem certificações caras pra ele.

Depois fui brincar com o PG (não há o que discordar que ele é um banco completo), mas vi o quanto é difícil achar hospedagem barata pra ele. E depois disso, o MySQL (há uns bons anos já) passou a suportar tudo que eu precisava (foreign keys, transações, etc).

Resumindo: a facilidade, a inércia e as melhorias do próprio MySQL me fizeram continuar com ele nos projetos web.

Rodrigo Amorim: concordo com tudo, exceto que sou contra ficar usando funções não-padrão do SQL. Isso amarra demais o software ao banco, já tive que migrar de SGBD, e foi um parto livrar o soft das funções proprietárias.

http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

Acrescentando um pouco de minha experiência com os dois. Alguns anos atrás eu estava trabalhando em sistema de que usava geoprocessamento. O sistema estava lento e foi identificado que o problema da lerdeza era o banco. Era o Postgres usando a extensão PostGIS.Pois bem, alguém bradou lá que a culpa era do Postgres e sugeriu usar o MySQL. Alguns testes e pimba com o MySQL era incrivelmente mais rápido. Eu achei estranho, pois em matéria de geoprocessamento o Postgres era muito mais reconhecido. Daí parti do princípio que o banco estava mal configurado, na verdade estávamos usando as configurações padrões.Estudei bastante como configurar o banco e pimba o Postgres ficou incrivelmente mais rápido do que o MySQL. Creio que com alguns ajustes o MySQL melhoraria, mas não a ponto de superar o Postgres naquela tarefa específica.

Texto longo, mas praticamente tudo correto.

Só alguns pontos a acrescentar. A otimização e controle de transações feitas com PHP nem é o pior. O pior para mim é fazer restrições de integridade via PHP.

Os SGBDs têm esse recurso a anos. O PostgreSQL além de chaves estrangeiras e únicas ainda tem recursos mais avançados como as Rules e criação de tipos pelo usuário. Isso combinado ainda com triggers permite um controle muito melhor.

Restringir via código é uma idéia que se alega como melhor porque a pessoa implementa na linguagem que domina, PHP, digamos. Ok, é válido. Porém, se toma isso como perfeito porque se desenvolve num ambiente centralizado, um servidor Apache/PHP que acessa o Banco. Se houver mais de um servidor, aplicações diferentes, isso já muda. Se a pessoa for organizada, vai fazer uma camada controlando essas restrições. Reinventando a roda, bastaria estudar um pouquinho para criar tudo no banco.

Outra: O MySQL é bem limitado no SQL. Aninhamentos mais complexos já falham. Esse é outro ponto, se usassem SQL direito(em qualquer banco), nem precisa aprender tanto assim, evitaria-se muita implementação no código. Aqueles vários laços while/For sumiriam. Ficar colocando IF isso, ou aquilo, também. Código que daria muito menos trabalho, menos propenso a erros.

Eu como usuário PostgreSQL, posso ser suspeito de falar isso, mas acho que o PostgreSQL é muito mais estável e robusto que o MySQL. Não é a toa que o chamo de “Oracle sem penas”.

Porém, é FATO: pelo menos na web, o número de banco de dados MySQL em ação é infinitamente maior que os equivalentes em PostgreSQL. Aliado a isso, muitos projetos (se for para exemplificar pelo menos um deles, cito o clássico Word Press) utilizam exclusivamente o banco de dados MySQL.

PONTOS A FAVOR

Uma das coisas que tenho visto, é que, dentre os bancos de dados “versáteis” SL/CA que vem “de fábrica” embarcados e “pŕe-configurados” em qualquer distribuição Linux de respeito, o MySQL parece vir mais “pronto pra uso” que o PostgreSQL. Acredito que o que espanta também o pessoal ao usar o PostgreSQL é essa alta “energia inicial de ativação” (normalmente a primeira barreira é sempre a mais alta). Para utilizar o MySQL, essa barreira é infinitamente menor!

Já no PostgreSQL o usuário precisa saber mais sobre as configurações de serviço, criação de usuários, uso de senhas e criptografia, tudo junto! Tudo isso precisa ser “refinado” antes de sequer começar a brincar com o mesmo. E nem estou falando ainda da configuração global como número de conexões, memória, etc, pois estou citando o uso de banco de dados para uso comum (ou mais conhecido como sub-utilização de recursos: malharei sobre isso mais abaixo), onde não se usa nem 5% da capacidade de um PostgreSQL ou de um MySQL.

Nos MySQL embarcados nos Linux, os usuários praticamente não precisam “fazer” nada. Acredito que muito dessa facilidade não se deve somente as pré-configurações “em ponto de bala” para uso do MySQL. Venhamos e convehamos, projetos como o Word Press são os que mais disseminam o uso e a aceitação do MySQL via Web.

PONTOS CONTRA

Nem toda essa facilidade se traduz em conhecimento de banco de dados. Claro que podemos dizer que a maioria dos banco de dados MySQL em uso na Web estão sob um Word Press ou Joomla! da vida. Note que os “desenvolvedores” de banco de dados MySQL atualmente em uso na web, são minoria. A maioria é usuário final de um ICMS (e de tabela, “usuário” de banco de dados).

NOTA: Não estou menosprezando ninguém, somente afirmando. Afinal, a tecnologia está aí pra isso. Contribuir para o crescimento e integração de todos nós e nos facilitar (sem escravizar) no nosso dia-à-dia. Não esperem que toda a população da Terra, com a integração digital, sejam desenvolvedores. A maioria sempre vai ser USUÁRIO FINAL e isso tem de ser respeitado. Inclusive, baseado nessa afirmação, os desenvolvedores devem sempre se preocupar em desenvolver software voltado para esse público. O Software não tem de ser fácil e intuitivo para você, mas sim para o usuário final.

Outro problema que podemos citar é a “profundidade” desses mesmos bancos de dados (nesse caso não estou falando do Word Press, pois eles usam mais recursos de banco que muito desenvolvedor por aí) ;-)

A maioria dos bancos de dados MySQL são simples tabelas soltas, praticamente sem nenhum relacionamento (quanto mais o uso de funções, etc). Dou minha cara a tapa se a maioria dos bancos de dados MySQL desenvolvidos pelos usuários para uso na rede, usam mais do que 5% da capacidade desse software (já escondendo a cara pra ninguém bater é claro). :-D

Sim! A maioria esmagadora prefere utilizar todo o relacionamento com o “banco de dados” (também conhecido como tabelas soltas) via PHP ou qualquer outra linguagem de script, para efetuar as transações com o banco de dados.

Se a PRIMEIRA AFIRMATIVA, que o PostgreSQL possui muito mais capacidade, fujncionalidade e robustez que o MySQL, estiver CORRETA, e se a SEGUNDA AFIRMATIVA, onde digo que os usuários MySQL não utilizam nem 5% da capacidade do seu banco de dados preferido, também estiver CORRETA, temos um ENORME PROBLEMA.

NOTA 2: Claro que, no mundo da informática, essa questão da porcentagem baixa de uso, não se restringe somente a banco de dados, mas a maioria esmagadora de programas em uso nos dias de hoje.

Baseado nessas afirmativas, aqui vai minha alfinetada na galera: por que a maioria dos desenvolvedores não procuram se aprofundar nos bancos de dados que tanto “apoiam”?

Muitos podem vir a questionar que, o uso aprofundado de mais de uma tecnologia em conjunto, gera comflito. E o mais chato, é que isso não está muito longe da verdade! (mas também não está completamente certo”)

Vejam como exemplo: o uso de um framework em PHP como o Zend com um banco de dados so tipo PostgreSQL ou MySQL. Muitas pessoas (e quero deixar bem claro que eu não concordo com isso) preferem fazer todas as transações de banco via PHP. Mais especificamente via funções do Zend para os bancos de dados. Com isso o pessoal é incentivado a literalmente criar tabelas soltas e fazer todo o tratamento de dados do banco via “PHP”. Acho isso um mal uso sem precedentes dessas duas “ferramentas”.

E não é só no uso de frameworks que isso acontece. isso começou muito antes do uso de frameworks. Antes de toda essa popularidade do Zend e cia, a maioria dos projetos web de integração com banco de dados, se tivesse uma única função no banco era milagre. A maioria queria tratar tudo na camada Web e deixar o “possante” banco de dados constituído única e exclusivamente de tabelas soltas…

Claro que algumas tecnologias podem gerar conflitos desse tipo, mas só com mais de 30% de uso de cada um dos softwares relacionados.

Minha sugestão é que o pessoal tente aproveitar melhor “todas” as funcionalidades do seu banco de dados. Não adianta quererem tratar tudo via web. Boa parte das “otimizações”, podem e devem ser conseguidas via banco de dados. É lá embaixo, na camada banco, que você pode começar a otimizar seu sistema. E se depois de tudo isso, você ainda conseguir aplicar “otimizações cumulativas” pela camada Web, melhor ainda!

RESUMINDO

Por que essa briga toda de quem é o melhor banco de dados, se ninguém aproveita as ferramentas que tem? Claro que pela “facilidade” de pronto-uso do MySQL, vemos muito mais casos desse tipo com esse banco. Existem casos de mal uso de PostgreSQl também, mas em muito menor quantidade. Ao meu ver, o pessoal que o utiliza, presta mais atenção a uma boa construção de bancos de dados quando de posse dessa ferramenta.

Mas esse é apenas o meu ponto de vista :-) Agora o povo pode começar a me malhar XDDDDDD

Ah! E gostaria que o povo, não só fornecesse suas opiniões quanto ao texto que escrevei, mas também que falassem de seus próprios casos de uso de seus bancos de dados (MySQL e/ou PostgreSQL). Gostaria de mais dados sobre a facilidade de adoção do MySQL em projetos web (principalmente) e como poderemos aplicar essas vantagens em outros projetos SL/CA de banco de dados.

Boa noite a todos!

Tem razão em dizer que há rivalidade entre usuários de PG e Mysql, mas é muito menor que as outras como citou.

“O que não pode acontecer, é a gente perder uma plataforma de banco de dados como essa.”

Se o MySQL sumisse hoje do mundo e magicamente qualquer fork e fontes dele junto o mundo seria uma catástrofe porque basicamente tudo feito em PHP roda sobre mysql.

Mas tecnologicamente, não se perde praticamente nada. O MySQL é bom e casou bem com o que se propõe principalmente, Web: muita leitura simultânea, pouca escrita, poucas ou nenhuma transação.

Do ponto de tecnologia o MySQL é somente bom. Mesmo o Firebird, menos famoso da turma, tem stored procedures e chaves estrangeiras desde a antiga versão 1.5 (talvez antes) de anos atrás.

Esse caso do MySQL está trazendo a tona que acontece muito de escolhas baseadas na paixão, ou simplesmente inércia.

Com esse tipo de comportamente se está perdendo uma excelente chance de estudar alternativas. Software Livre não é somente gratuidade, é muito também sobre ter alternativa. Evitar o problema de dependência de um fornecedor.

E agora que um software livre famoso foi para controle de uma empresa, essa era uma deixa excelente para lembrar disso: alternativas.

Então, quem pode pagar isso? A Oracle, pode. Este negócio fede de cima para baixo. “Sun e Oracle, têm sido parceiros estratégicos, à anos.”

MySQL na mão da ORACLE é o mesmo que a Microsoft comprar o linux!

Agora para os usuários Postgree digo, usuários MySQL e Postgree nunca se deram, é o mesmo quem programadores DELPHI e VB ou ainda, querer que os Corinthianos se deêm com os Santistas nesse final de campeonato.

O que não pode acontecer, é a gente perder uma plataforma de banco de dados como essa.

Você acha que todas as empresas que citou usam o MySql em missão critica? Realmente entendo agora porque falou que trocou o Postgres porque era péssimo, seus comentårios falam por si.