| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | Este tema aparece de tempos a tempos. O problema é que tipicamente quem faz os benchmarks não percebe a diferença entre uma motor SQL (MySQL) e uma base de dado completa (PostgreSQL).
|
| | | | | | O departamento deveria ser auto-explicativo :)
Ainda assim, parece-me interessante ver as comparações que se conseguem fazer, abstraindo-nos das diferenças brutais entre os dois.
"I explicitly give people the freedom not to use Perl as God gives people the freedom to go to the devil if they so choose." - L. Wall |
| | | | Ja agora podes-me explicar qual as diferenças ao pormenor entre eles? É que eu sou uma dessas pessoas;)
|
| | | | Parece-me que o MySQL goza de uma certa popularidade devido ao "efeito carneirada". Deixam-me explicar. Eu conheco uma data de pessoas que usa o mysql e que jura a pes firmes que e' a melhor db do mundo, simplesmente porque:
- nunca experimentou outra
- experimentou outra e deu-se mal
- na altura as outras eram mesmo mas
- [your reason here] . . .
- mas acima de tudo, porque a maior parte do pessoal usa mysql
Pela minha experiencia, que ja' usei mysql tambem, e que uso postgres desde a versao 6.3.x, vejo grandes diferenças entre as versoes do postgres, para melhor claro. O facto de suportar triggers, views, transactions, etc, eliminou logo o mysql, porque eu precisava disso, e fiquei-me pelo postgres. No entanto, tentei acompanhar o mysql, porque nao me gosto de sentir preso a um produto. Se o mysql passar a ser melhor, passo a usa-lo.
Isto tudo para dizer que o postgres tentou muito cedo ser uma DB bastante completa, enquanto o mysql, seguiu o caminho de ter poucas features e ser rapido (para selects, apenas). No entanto o postgres evoluiu e passou a ser rapido tambem, e o mysql ainda esta' a fase de tentar suportar novas features, perdendo o que tinha de bom: velocidade.
Para os que ainda não testaram o postgres, recomendo que testem a versao 7.0.3 e comparem.
Saliento ainda as diferenças ao nível do codigo. Se tirarmos partido das transações do postgres fica muito mais simples o nosso código, que se usarmos mysql, devido os "truques" necessarios de efectuar no mysql para garantir a mesma coerencia das DB.
A próxima que vou experimentar, assim que tiver algum tempo, é o Interbase 6.0. Pelas "features" parece-me estar muito bom, mas nada como experimentar-mos nós mesmos.
Neste momento sinto falta de uma coisa no postgres, que ja' existe no mysql: replicação. E' um dos projectos em curso no postgres e deve estar pronto rapidamente *espero*. Para ja' ainda não é critico a utilização de replicação, mas se necessitasse ja' disso, era mais uma razao de testar Interbase 6.0, que suporta replicação, transações, etc.
|
| | | | | | Eu uso MySQL nas poucas coisas que faço que precisam de uma base de dados porque não preciso de mais. Na realidade poderia utilizar dbm, mas sou preguiçoso :)
Em coisas que teem que suportar muitos utilizadores concorrenciais a mexer muito nas tabelas o MySQL perde-se totalmente em locks :)
|
| | | | Acredito que para muitas coisas o MySQL seja suficiente, mas la' por termos um Ferrarri temos que andar sempre a 200? Ter nao temos :)
O postgres nao gasta mais que o mysql (memória, disco, etc). Poderemos não tirar partido hoje de todas as features, mas quando necessitarmos vamos instalar os 2 (mysql e postgres)?
Eu sou da opiniao que mais vale usar o melhor (dentro do razoavel, claro), e depois se necessitar de mais ja' ca' esta'. Alem do mais, ha' um conjunto de features que nao necessitamos ate' que elas estejam disponiveis e nos habituamos a usa-las. Depois não sabemos como pudemos passar sem elas.
De qualquer forma acho que e' importante e' nao usar features obscuras que apenas uma DB tenha. Por exemplo, o postgres tem o suporte de objectos. Como nao conheco mais nenhuma que suporte isso da mesma forma, se eu utilizar isso, fica muito dificil migrar para outra base de dados no futuro. Assim evito utilizar essa "feature". Utilizo o mais possivel SQL "standard", que assim sera' facil manter uma certa independencia da DB.
|
| | | | Boas! (a minha estreia por aqui) Se quando mencionas "objectos" te referes a BLOB e CLOB (Binary Large Object e Character Large Object, se nao me engano), tens ambos os datatypes em Oracle (versoes 7 para cima). Nao te sei responder agora de repente se estes objectos pertencem ao standard SQL-92, mas sao suportados por varios interfaces de programacao e e' um tipo de dados muito "agradavel" para guardar fotos, por exemplo.
|
| | | | Nao. Refiro-me ao Object Oriented que o Postgres suporta. Pode definir tabelas que derivam de outras e coisas assim, tal como na programação por objectos. Não tem nada a ver com os BLOBs.
|
| | | | Viva!
E ainda há a documentação.
Eu tenho que migrar muito brevemente umas cenas que fiz antes em ASP/access (puah!) para PHP.
Quanto à db, hesitei entre postgreSQL e MySQl.
Acabei por optar pelo MySQL, pois consegui encontrar muito mais documentação do que para postgreSQL.
Mesmo a documentação que há para PHP em relação a dbs, se relaciona quase sempre com o MySQL.
Enfim...
Se calhar também é o tal efeito carneirada de que falas :(
|
| | | por Anonimo Cobarde em 14-11-00 0:16 GMT (#8)
|
| Curioso. O referido artigo fala da documentação do Postgres como uma vantagem, em comparação ao MySQL. De qualquer forma, encontrei sempre a documentação necessária para os dois. E viva o Google.
|
| | |
|
