| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. |
| | Finalmente chegaram ao mesmo nivel que o PostegreSQL já está desde 1999!!
|
| |
| | | A julgar pela Release Note, o MySQL está tornar-se uma base de dados séria..
O reinado das BDs comerciais está definitivamente ameaçado... a menos que alguem ..os compre!
--> Obscenity is the crutch of the inarticulate motherfuckers -- |
| |
| |
| | Sim, agora só falta mesmo comparar a performance do MySQL contra bases de dados a sério *g*
|
| |
| | Isso já foi feito muitas vezes... A Net está cheia de exemplos. O que é preciso fazer é comparar usando as funcionalidades... Porque sem funcionalidades tudo funciona mais rápido :)
Cumprimentos.
|
| |
| | Claro não estava a falar dum select'zeco qq para comparar as coisas ;) Falamos de features realmente importantes nessas BD's "comerciais" e que o MySQL tenta ter...Quando a performance/funcionalidade for do mesmo nível, dou o braço a torcer :)
|
| |
| | "O reinado das BDs comerciais"
O que são BDs comerciais?
"I just want you to know that, when we talk about war, we're really talking about peace." — J.W.Bush, Washington, D.C. June 18, 2002 |
| |
| | err... deve-me estar a escapar algo, mas aqui fica a resposta:
DB2
Informix
Oracle
SQL Server
Sybase
Teradata
...
e... mySQL? :)
Cumprimentos, e explica onde querias chegar por favor.
|
| |
| | Perguntei o que são, não quais são.
Mas pela tua resposta, estou a ver que confundes modelos de licenciamento com valores de troca.
Lá por o PostgreSQL não ter um custo monetário associado para aquisição e para licenças de utilização não é menos 'comercial' que os restantes SGBDs.
A diferenção (fundamental) é que uns são software livre/aberto, outros não (ou _ainda_ não).
"I just want you to know that, when we talk about war, we're really talking about peace." — J.W.Bush, Washington, D.C. June 18, 2002 |
| |
| | | As base de dados conhecidas por "comerciais" são as seguintes: 1) Oracle 2) MS SQL Server 3) IBM DB2 4) Sybase ASE São estas que estão presentes nas empresas que as podem pagar. Juntas representam mais de 80% do mercado empresarial. As restantes ficam com as migalhas que sobram..
--> Obscenity is the crutch of the inarticulate motherfuckers -- |
| |
| | Faltam-te algumas...Informix, Teradata, Ingres (já terá passado a OSS) e uma de windows que não me lembro o nome.
Isto assumindo que restringimos às relacionais, caso contrário ainda aparecem mais umas (ex: IMS que agora está 'famosa' :) )
De qualquer forma apresentar números é arriscado porque (ainda) não há grandes dados sobre as OSS. A Gartner há uns dois anos começou a falar do mySQL mas penso que ainda não fez nenhum estudo rigoroso.
Cumprimentos.
|
| |
| | Estudo rigoroso sobre SL?? A Gartner??? right...
Além do mais, como é que é possível obter um estudo rigoroso de algo que é possível fazer o download da internet sem dar cavaco a ninguém?
---
Este espaço pode ser seu... |
| |
| | Bem... há estudos sobre tanta coisa... Apache, linguagens de programação, utilizadores de TM, utilizadores de ADSL etc.
As formas de fazer estudos são muitas... e uma delas é fazer inquéritos a empresas representativas.
Se confias nos estudos ou não é outra questão, mas certamente não é por se poder aceder a usa coisa "sem dar cavaco" que não se pode fazer um estudo sobre ela.
Cumprimentos
|
| |
| | Tudo bem... se quiseres discutir o termo 'comercial' fica à vontade. Eu abstenho-me disso. Penso é que quando se fala em "bd comercial" a maioria das pessoas associa a BDs que pagas para usar.
Foi precisamente por isto que estranhei a questão (e foi por estranhar que respondi apesar da resposta me parecer óbvia).
Cumprimentos.
|
| |
| | Mas "BDs comerciais" não equivale a "BDs proprietárias" ou "BDs não FOSS". Para evitar equivocos ou más compreensões, deve-se usar os termos mais correctos ao referir-se a algo. Como este forum é frequentado principalmente por pessoas com formação técnica e/ou superior, com certeza irão compreender muito bem isso e concordar.
|
| |
| | A MySQL só agora é que está a incorporar funcionalidade que bases de dados FOSS como a PostgreSQL já tem desde 99. Por consequência, não é assim um acontecimento tão revolucionário como tentas pintá-lo.
|
| |
| | | A diferença é que o MySQL tem um apelo verdadeiramente popular. As que referes têm tido um percurso mais ou menos obscuro..
O MySQL é desenvolvido por uma empresa .. e é alemã. Isso faz toda a diferença.
--> Obscenity is the crutch of the inarticulate motherfuckers -- |
| |
| | Uma correcção. A empresa é Sueca: http://www.mysql.com/company MySQL AB Founders The company was founded in Sweden by two Swedes and a Finn: David Axmark, Allan Larsson and Michael "Monty" Widenius who have worked together since the 80's. MySQL AB is the sole owner of the MySQL server source code, the MySQL trademark and the mysql.com domain worldwide. The company is privately held and without debt, and it is financed by venture capital since July 2001.
|
| |
| | "SQL Mode -- provides server-enforced data integrity for new and existing data;"
Alguém se deu ao trabalho de perceber o que é isto?
Cumprimentos.
|
| |
| |
| | The MySQL server can operate in different SQL modes, and can apply these modes differently for different clients. This allows each application to tailor the server's operating mode to its own requirements.
Modes define what SQL syntax MySQL should support and what kind of data validation checks it should perform. This makes it easier to use MySQL in different environments and to use MySQL together with other database servers.
http://dev.mysql.com/doc/refman/5.1/en/server-sql-mode.html
My son is now an "entrepreneur." That's what you're called when you don't have a job.
Ted Turner |
| |
| | | Uma das regras no mundo das bases de dados é que a integridade dos dados é definida na base de dados e as aplicações não podem passar por cima disso. No caso do MySQL, em funcionamento normal, se tentares inserir dados inválidos, ele corrige-os para valores que pensa estarem correctos. O que é inaceitável em ambientes que necessitam de integridade dos dados que mantêm. A versão 5 suporta o funcionamento normal, de dar erro na tentativa de inserção de dados inválidos. (Mas a aplicação pode desligar isso, o que reduz a sua utilidade.) Para alguns problemas que isso traz, e outros do MySQL, ver MySQL Gotchas.
hugs
Strange |
| |
| | Urra, urra... Por favor porte-se bem, mas se quiser corrompa tudo :)
Obrigado pelo esclarecimento.
|
| |
| | Como já corrompia até agora. Pelo menos já deixam os mais "voluntariosos" portar-se bem.
--
Jazzy |
| |
| | No caso do MySQL, em funcionamento normal, se tentares inserir dados inválidos, ele corrige-os para valores que pensa estarem correctos. O que é inaceitável em ambientes que necessitam de integridade dos dados que mantêm.
já alguma vez usaste oracle, sql server, whatever? ele assumir que tu queres determinadas coisas é comum... e é essa uma das maiores fontes de problemas, ou dominas o sgbd ou isso é fácil de acontecer.
|
| |
| | E tu já usaste? Uma BD "a sério" dá-te sopa se fazes alguma coisa que viola as regras de integridade especificadas no DDL.
O tempo em que a gestão disso era garantida pelas aplicações já lá vai (felizmente...)
Cumprimentos.
|
| |
| | Já vem tarde... anda um gajo a aprender postgresql por causa dos triggers e procedures, e (só) agora o MySQL já tem... hmmm. Bem, de volta aos livros/google.
Feché la vache! |
| |
| |
| | Nao compares PostgreSQL ao MySQL. Não é por o mysql ter triggers e vistas e essas coisas, que podes comparar ao postgresql. O PostgreSQL é uma das base de dados mais potentes que conheço. Compara o PostgreSQL ao Oracle e não ao MySQL. O MySQL ainda vai demorar uns anos ate ter uma aproximacao do pl/pgsql Mas ainda bem que o MySQL se comeca a tornar uma BD a "sério". Vai trazer muitos beneficios aos programadores ("database based") como eu.
|
| |
| | Eu sou um confesso ignorante em relação PostgeSQL (nunca instalei nem utilizei), leio constantemente fervurosos adeptos do Postgres a realçar como este é melhor que o MySQL, podes-me dizer claramente as vantagens em relação ao MySQL para pequenas aplicações(onde trigers e stored procedures não fazem falta) ?
P.S: Isto não é flame, é curiosidade sincera.
|
| |
| | Não é por ser pequena que uma aplicação dispensa features...
A mim, sem nunca ter usado nenhuma das duas, o mySQL aparece-me como uma "manta de retalhos". Queres transacções usas o InnoDB. Queres outra coisa usas outra...
Ou seja, o mySQL não é uma BD mas sim uma abstracção de outras que estão lá por baixo.
Mas isto deve ser um bocado como o Windows... ter sido (ou ainda ser) mau nunca o impediu de vingar. :)
Também estou curioso para ver outras respostas ao teu post
Cumprimentos.
|
| |
| | Na minha opinião, a animosidade contra o MySQL não se prende apenas com as features que não tem, mas também com a filosofia de desenvolvimento do MySQL. E essa filosofia aparenta ser: a prioridade é a performance em queries simples. Tudo o resto é secundário. Lidar eficientemente com queries complexas, garantir integridade dos dados ou implementar a lógica da aplicação no RDBMS aparentam ser secundárias para a MySQL AB e só surgem quando se torna quase ridiculo não ter.
Por exemplo, o suporte para transacções apareceu porque já era mesmo abuso não ter. E mesmo assim, ambos os backends com suporte para transacções do MySQL são desenvolvidos por duas outras empresas.
As pessoas que utilizam RDBMS na forma mais tradicional (isto é, e não para colmatar a falta de persistência nas plataformas de web) obviamente não querem um RBDMS assim que parece andar sempre um passo atrás, mesmo que num dado momento esse RDBMS tenha todos os bells and whistles que acham interessantes para a sua aplicação.
|
| |
| | Ok, isso de certa forma leva-me a concluír que provávelmente as "massas" deram mais importância à performance em queries simples do que à integridade referencial, transações e outras funcionalidades que durante tanto tempo deixaram o MySQL "atrás" em comparação com o Postgresql ou outros RDBMS comerciais, concordas ?
Estou a tentar perceber a razão da popularidade "quantitativa" do MySQL versus a popularidade "qualitativa" do Postsgresql.
|
| |
| | | Concordo. Noutros tempos, a performance do MySQL (pelo menos nas tais queries simples) era muito melhor que a do PostgreSQL e o MySQL era mais simples de administrar. As pessoas precisavam de um mecanismo de persistência para as suas webapps e o MySQL serve muito bem esse propósito. Dai, imensos serviços de hosting e webapps funcionam com MySQL. Daqui vem a popularidade "quantiva" do MySQL.
Com o PostgreSQL 7.x, a vantagem de performance do MySQL vs PostgreSQL esbateu-se muito. E com isso, pessoas que tinham preferido o MySQL começaram a reparar que o PostgreSQL tinha uma parafernália de funcionalidades tipicas dos RDBMS "a sério" enquanto que no MySQL essas funcionalidades pareciam estar a ter um parto dificil e com uma mãe pouco cooperante. Daqui vem a popularidade "qualitativa" do PostgreSQL.
|
| |
| | Bravo. Obrigado pela análise. :-)
|
| |
| | Uma das principais vantagens do mysql são as suas APIS, que estão muito bem feitas e existem praticamente para todas as plataformas/compiladores.
Tem outras desvantagens como foi dito, que é a integridade dos dados nao é garantida (versoes anteriores a 5.0 - Não falo da 5.0 pq ainda nao testei. E penso que esta sim, esta muito boa).
Eu tenho uma empresa de software, onde a regra é a base de dados faz praticamente tudo, ou seja, as aplicacoes sao simplesmente um frontend para os dados. Até hoje o MySQL não permitia isso. Um exemplo de não respeitar a integrade dos dados é este: ter uma tabela com campos not null e unique, e ele deixar inserir campos null(penso que isto e o cumulo, mas aconteceu comigo).
Com o PostgreSQL o programador tem mais poder nas maos, ou seja, pode fazer mais e melhor.
AH, não se esquecam de outra excelente BD que anda ai, que uso em umas poucas de aplicacoes (Firebird). No meu ver, ate a versao do mySQL 5.0, o firebird era muito superior. Vamos a ver esta nova versão.
Estou curioso. :)
|
| |
| | Eu tenho uma empresa de software, onde a regra é a base de dados faz praticamente tudo
come again?! como é que escalam horizontalmente a aplicação? metem mais BD para lidar com aquilo que deveria ser a camada de negócio?
---
Este espaço pode ser seu... |
| |
| | Curiosidade... a que camadas te referes?
Obrigado e cumprimentos.
|
| |
| | Só a uma, a que faz os cálculos. Se quiseres calcular o resultado de 1+1 podes fazê-lo na BD com uma função.
Se um milhão de pessoas estiver ao mesmo tempo a calcular 1+1, vais ter de escalar de alguma forma o sistema se este não aguentar. Ao teres isto embutido na BD, vais ter de fazer um cluster de BDs para calcular 1+1. Estás a meter cálculos na camada de dados: sucky sucky.
---
Este espaço pode ser seu... |
| |
| | Ok... estava curioso se estavas a pensar em algo mais sistematizado. Algum modelo ou assim.
Ainda assim há uma razão para meter o 1+1 na BD. Podes aceder à BD com várias aplicações, linguagens e ambientes. Se o 1+1 tiver numa stored procedure por exemplo é mais fácil de manter. Isto não significa que não tenhas razão... Depende muito do ambiente...
Cumprimentos.
|
| |
| | Concordo 100% contigo. É suposto suposto o SGDB "não saber fazer cáculos". A aplicação sim. Há excepções claro. Situações que obrigam a recalcular valores: por exemlo, alterar os preços de 1 ou n famílias de artigos.
|
| |
| | O advento do MySQL em plataformas web deve-se a uma questão muito simples: o MySQL é, em termos de recursos, muito mais leve que o Postgres em ambientes de webhost massivo. Regra geral, os servidores de webhost partilhado não são "nada de especial" em termos de características e em muitos casos as BD's correm na mesma máquina onde corre o resto da "tralha" (perl, php, python, apache, etc). Por exemplo, se a utilização do Postgres significar que não se metem mais 10 ou 20 clientes na mesma máquina, é normal que muitos provedores comerciais optem pelo MySQL.
Why do you Linux and drive when you can BSD and fly? |
| |
| | Claro, não estou a comparar, estou a dizer que não pude utilizar MySQL apenas porque preciso MESMO de triggers e procedures. E a solução que encontrei na altura com esses requisitos, em open-source, foi postgresql...
Feché la vache! |
| |
