<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Já ouço falar destas "inovações" do MySQL a anos e estou esperando até
agora...<br>
Mas infelizmente nesta aplicação que eu falei não tenho alternativa,
além de rezar que a 5.0 chegue logo ao estável, com todos os recursos
prometidos...<br>
<br>
Em relação a performance aprendi uma coisa: nem sempre o mais rápido é
o melhor... Gosto de um comparativo: será que o carro mais rápido é o
melhor, ou será que a gente deve avaliar outros ítens, como câmbio,
pneus, estabilidade, etc?<br>
<br>
<br>
SDS,<br>
<br>
Luciano<br>
<br>
<br>
<br>
<br>
Nilson Santos Figueiredo Junior escreveu:
<blockquote cite="mid9a08c9b40507281051561b621e@mail.gmail.com"
type="cite">
<pre wrap="">On 7/28/05, "Er Galvão Abbott - PortoAlegre.pm" <a class="moz-txt-link-rfc2396E" href="mailto:galvao@perl.org.br"><galvao@perl.org.br></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Por isso que eu só uso PostgreSQL. Os que gostam que me desculpem, mas mySQL
pra mim é lixo.
</pre>
</blockquote>
<pre wrap=""><!---->
Se você implementar algo que lê arquivos CSV, onde cada arquivo CSV
representa uma tabela, e permite que sejam feitas buscas relacionando
um arquivo CSV com o outro, você tem um banco de dados relacional. A
diferença é que não é o que eles chamam de enterprise class RDBMS.
Até a série 4.x o MySQL não é um RDBMS enterprise class.
Pelo tipo de comentários que li nessa discussão, parece que ninguém
conhece a série 5.x do MySQL, que ainda não é a release stable. No
MySQL 5.0 é introduzido suporte à todos os recursos que foram citados
na discussão.
Quem se interesse, pode ler em:
<a class="moz-txt-link-freetext" href="http://dev.mysql.com/doc/mysql/en/mysql-5-0-nutshell.html">http://dev.mysql.com/doc/mysql/en/mysql-5-0-nutshell.html</a>
Lembrando que, atualmente, não existe RDBMS com melhor performance que
o MySQL 4.x, salvo o SQLLite para alguns casos. Os concorrentes
apontam que isso se deve ao fato de o MySQL 4.x não ter recursos de
uma enterprise class RDBMS, o que faz sentido. O lance é testar e ver
se ele conseguiu manter a performance na série 5.x.
Alguém citou o lance da primary key com NULL. Isso é um *recurso*. Se
você quiser, pode não permitir NULLs nela. Não consegui achar nenhum
tipo de referência quanto ao MySQL não controlar o fato de colunas com
"NOT NULL", pelo contrário. O único problema dele é quando você dá um
ALTER TABLE criando uma nova constraint NOT NULL para alguma coluna:
ele, silenciosamente, altera tudo que era NULL para 0, desconsiderando
outras possíveis constraints, foreign keys, etc, ao invés de falhar o
comando. Mas fora isso, não tem outros problemas.
Note que eu não uso MySQL normalmente, apenas estou tentando mostrar
que muitas das coisas que pensam sobre ele é apenas cargo-cult. E que,
atualmente, ele tem seu espaço muito bem definido: banco de dados
simples e blazing fast. Com o 5.0 indo pra estável, veremos o quão bem
ele irá se comportar como um competidor direto na arena das enterprise
class RDBMS. Acredito que terá dificuldades, pois terá todo esse
folclore associado - o mesmo que acontece muitas vezes com Perl, ou
vocês nunca ouviram alguém falar que "Perl é write-only bla bla bla" ?
-Nilson Santos F. Jr.
_______________________________________________
Cascavel-pm mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Cascavel-pm@pm.org">Cascavel-pm@pm.org</a>
<a class="moz-txt-link-freetext" href="http://mail.pm.org/mailman/listinfo/cascavel-pm">http://mail.pm.org/mailman/listinfo/cascavel-pm</a>
</pre>
</blockquote>
</body>
</html>