Fundador do MySQL convida Oracle para conversar sobre estratégia de código aberto
Monty Widenius, fundador do projeto MySQL, convidou Larry Ellison para uma conversa sobre a estratégia da Oracle para o código aberto em geral e o MySQL (recém-adquirido, incluído no bojo da Sun) em particular.
Ele crê que a Oracle tem basicamente 3 opções: manter o MySQL, encerrar a linha corrente de desenvolvimento do MySQL, ou repassá-lo a outra empresa.
Ao mesmo tempo, ele informa que se a coisa ficar difícil, a empresa dele está preparada para contratar os desenvolvedores centrais do MySQL. (via heise.de)
Saiba mais (heise.de).
• Publicado por Augusto Campos em
2009-04-24
@brlinuxblog
Feed RSS
Sério isso já ficou confuso, pois primeiro desenvolve o MySQL e a MySQL AB, depois vende para SUN e agora quer o código de volta para continuar desenvolvendo. Será que pode chamar isso de efeito bumerangue???
boto fé no cara.. ta ai a certeza que não vamos ficar na mão :D
( não desmerecendo a notícia, que é muito importante para a área, maaass…)
Ainda no aguardo de notícias sobre o openoffice.
I’m a simple user!
Repasso aqui uma sugestão do meu chefe… Se a Oracle não quizer o MySQL, que o Monty Widenius chame o fork de OurSQL!!
Não seria YourSQL? Mas já vi esta piada antes:
Fedora Weekly Webcomic: Unbreakable Prophecy
heheh
Ta na cara que deve ser um fork do Mysql que ele está falando , e ai os antigos desenvolvedores do Mysql nele iriam contribuir muito.
E concerteza nessa conversa sobre código aberto em geral o OpenOffice.org deve estar no meio.
Fora que se for pensar direito , a Sun já deve ter falado sobre o OpenOffice e outros projetos abertos para a oracle.
Só falta o Larry agir direito e não como um dos 3 patetas.
“Fundador do MySQL convida Oracle para conversar sobre estratégia de código aberto”
Se o Larry Ellison responder “F**a se, já paguei.” não ia ser exagero algum.
Sério, o cara vende por um valor exorbitante e fica apurrinhando depois ? Pior apurrinhando o comprador do comprador ?
Deve estar querendo criar polêmica. Poderia tentar divulgar seu fork sem esse tipo de posição rasteira.
Mete a cara no trabalho e pronto. Com certeza muita gente ia seguir ele, e adotar o fork.
Ele está mostrando o que sempre foi o mySQL, uma bagunça, mais vaidade que trabalho.
PostgreSQL continua lá, um projeto, sem ter dono, e com todo mundo trabalhando para ficar ainda melhor.
Quer algo diferente ? Firebird.
Algo mais leve? SQLite
Mais adequado aos tempos web e OO? CouchDB
Muitas alternativas, algumas superiores. Essa história de se apegar só por carinho não cola. Parece o povo chorando pelo Kurumin, quando o próprio Morimoto dizia que não tinha mais motivo de continuar.
Concerteza .. já estou estudando o PostgreeSQL.. se eu me adaptar bem vou migrar pra ele. sempre vai existir varias opções no mundo do SL.
PostgreSQL rules !!! XDDD
Brincadeiras a parte, realmente seria uma perda enorme para a Comunidade SL/CA ver o MySQL ser morto (e pelo visto, aos pouquinhos e com requintes de crueldade).
Mas além dos forks, os usuários MySQL podem começar a ver com mais “carinho” o PostgreSQL, considerado a tempos um “Oracle sem penas”. ;-)
Porém, visto o poder desse banco de dados (e sendo usuário exclusivo dele, já que nunca me interessei em utilizar MySQL profissionalmente), gostaria da opinião de vocês (usuários MySQL), para saber o que fizeram vocês escolherem o MySQL ao invés do PostgreSQL. Toda informação é válida!
Gostaria desse feedback de vocês, se possível. As informações oferecidas por vocês podem ser muito úteis, não somente para o desenvolvimento e ações de aceitação do PostgreSQL, mas para o desenvolvimento de qualquer banco de dados SL/CA.
E, para finalizar, vamos torcer para que o MySQL seja salvo de uma possível passagem de ida sem volta para o /dev/null da história. Faço votos para que seus usuários se unam e criem forks do projeto original. E que se estruturem profissionalmente em seu desenvolvimento, para que possam seguir adiante, e nada se perca de todos esses anos de liberdade na forma de banco de dados.
Na empresa onde trabalhei, tiveram dois fatores que nos levou a abandonar o Postgres:
- depois que as tabelas começaram a enfrentar acesso concorrente de mais de 100 conexoes, o sistema começou a aumentar a frequencia de deadlock
- tínhamos grandes problemas de performance, mesmo com as querys otimizadas e com índices. Procuramos uma empresa que pudesse nos dar suporte para contratar a ajuda, mas não encontramos na região.
Com MySQL conseguimos resolver os dois problemas e quando saí já tinha acesso concorrente de mais de 300 conexões sem nunca ter tido deadlock e com um sensível ganho de performance se comparado ao Postgres.
Deadlocks? Desculpe, mas para mim isso é causado por uma configuração PÉSSIMA. É para isso que serve um DBA com conhecimento avançado no banco de dados. Não é incompetência. O problema é que certas empresas que não entendem que um bom DBA faz toda a diferença.
Eu acho que foi superado algum limite de velocidade quando você passou da afirmação de que em uma determinada situação, e para uma determinada aplicação, ocorrem deadlocks, diretamente para a conclusão de que a origem é uma configuração “PÉSSIMA”, associada à ausência de um DBA com conhecimento e a um julgamento de que determinadas empresas não entendem a importância de um DBA habilitado.
De minha parte, acredito que possa haver um grande conjunto de outras explicações, que não se limitam a (mas também não excluem, naturalmente) possibilidade de que o DBA não tenha o conhecimento necessário, ou que a empresa não valorize a atividade dos DBAs.
Adotei o mysql em 2005, pelo desempenho e flexibilidade que oferece. Eleito como uns dos bancos de dados mais rápidos do mercado e que sempre bateu de frente com a oracle com campanhas economize $1.000.000,00. A Nasa trocou ORACLE por MYSQL, Yahoo Finance, Banco Bradesco, U.S Federal Reserve System, Dataprev, Google usam mysql, entre outras organizações. Agora o MYSQL na mão do concorrente!!! Isso não pode acontecer mesmo! MySQL na mão da ORACLE é o mesmo que a Microsoft comprar o linux! Isso é uma coisa que não deveria ter acontecido. :-(
100 Conexões ?
“Jesuis ajuda”. Isso é micharia para o Postgres. Meu sistema usa o Postgres(8.3) com configuração de fábrica, média de 180 conexões. Tranquilo e sereno. E não é só leitura não.
Só falta dizer que foram para o MySQL e tiraram todas chaves estrangeiras. Como é hábito no mundo dos golfinhos.
[ironia]
Chave estrangeira? Para que?
Formas normais? Não serve para nada…
[/ironia]
Rodrigo,
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.
Como pode uma empresa oferecer o preço de $ 1 bilhão para a aquisição do MySQL, quando o objetivo só traz em cerca de US $ 60 milhões na receita?
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.
Rodrigo: “Postgres” ou “PostgreSQL”. Não existe “postgree” ou “postgri” :).
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.
Eu troquei o MySQL pelo SQLite já há vários meses, e posso dizer que estou bastante satisfeito.
Muito obrigado pelo Feedback de vocês. :) Agora vai a minha contribuição também. Vou falar de forma simplificada o meu ponto de vista.
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).
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.
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!
@Rodrigo
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.
aqui tem um artigo interessante sobre essa velha briga
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.
O motivo do sucesso do MySQL?
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.
Se pararmos pra olhar bem, o MySQL é um dBase com hormônios. :)
Oi Pessoal,
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 erramenta 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.
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! :-)
Rodrigo, obrigado pelo comentário sobre o artigo. Na verdade o artigo traga mais da diferença entre os bancos, e, após o software rodar no cliente com Oracle, continuo usando MySQL ou Postgres mesmo :P
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! :)
Pergunto aos usuários do PostgreSQL:
- é 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…
@Marcos
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! ;-)
Olá Rodrigo Amorim. Muito, muito obrigado pela resposta e pelos links! Resposta mais completa é impossível.
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!
@Marcos
Que bom que foi de ajuda :-) Se precisar de mais alguma ajuda ou dica, é só deixar um post aqui que eu respondo.