[Cascavel-pm] Linux+Perl+MSAccess
Rodolfo Sikora
sikora em inova.net
Quinta Julho 28 10:38:37 PDT 2005
Uso MySQL há 6 anos e nunca levei na cabeça.
Concordo qdo falam que mysql não eh um banco de dados, mas alguns não
lembram que não é toda aplicação que precisa de um "banco de dados" e dá
para se sair muito bem utilizando mysql.
Não fosse isto, NASA nem projeto genoma estariam utilizando mysql em
determinadas aplicações.
Acho q esse lance de BD é muito mais falta de saber o que vc vai fazer e
o que vc deve usar do que simplesmente não usar mysql.
Queria ver como o PostgreeSQL se sairia com minha aplicação de anti-spam
com alguns bilhões de tokens e mais de 3000 queries por segundo.
Por outro lado não consigo ver o mysql sendo utilizado numa aplicação
financeira ou uma aplicação gerencial/empresarial.
[]s
On Thu, 2005-07-28 at 13:13 -0300, "Er Galvão Abbott - PortoAlegre.pm"
wrote:
> Esse é exatamante o problema, Luciano: com o mySQL a gente só aprende
> levando na cabeça.
>
> Por isso que eu só uso PostgreSQL. Os que gostam que me desculpem, mas
> mySQL pra mim é lixo.
>
> Abraços,
> Er Galvão Abbott
> galvao em perl.org.br
> ----------------------------------------------------
> Fundador e Administrador - Porto Alegre Perl Mongers
> http://portoalegre.pm.org/
> ----------------------------------------------------
> Sócio e Diretor Técnico - Sociedade Perl do Brasil
> http://perl.org.br/
> ----------------------------------------------------
>
>
> Luciano Giordani Bassani wrote:
> > Queria que alguém tivesse me dito isso antes, a cerca de uns 5
> > anos... :ó(
> >
> >
> >
> > Er Galvão Abbott - PortoAlegre.pm escreveu:
> > > Três palavrinhas: NÃO USE mysql.
> > >
> > > mysql não possui integridade referencial (mesmo em tabelas INNODB)
> > > mysql não controla colunas NOT NULL
> > > mysql permite até mesmo que uma Chave primária seja setada para NULL
> > > (lindo não?)
> > >
> > > Veja: http://forums.mysql.com/read.php?20,30444,30444#msg-30444
> > >
> > > Portanto digo e repito: mysql não é um banco de dados relacional.
> > >
> > > Abraços,
> > >
> > > Er Galvão Abbott
> > > galvao em perl.org.br
> > > ----------------------------------------------------
> > > Fundador e Administrador - Porto Alegre Perl Mongers
> > > http://portoalegre.pm.org/
> > > ----------------------------------------------------
> > > Sócio e Diretor Técnico - Sociedade Perl do Brasil
> > > http://perl.org.br/
> > > ----------------------------------------------------
> > >
> > >
> > >
> > > Luciano Giordani Bassani wrote:
> > >
> > >
> > > > Na verdade eu creio que EU tenho mais dores de cabeças com uma base de
> > > > dados em MySQL do que meu chefe que gerencia esta mesa base de dados
> > > > (deste mesmo cliente) em MS Access. Mas são coisas da vida. A gente só
> > > > aprende "botando a mão na massa"... Hoje em dia, se eu pudesse,
> > > > converteria toda esta base de dados em MySQL para um PostgreSQL ou um
> > > > Firebird (apesar de não ter usado o Firebird em nenhuma solução
> > > > ainda), mas infelizmente uma migração destas tem um custo muito alto e
> > > > o cliente está satisfeito com o que ele tem. Eu é que sofro para
> > > > implementar "gambiarras" para as faltas de store procedures, triggers,
> > > > etc no MySQL (em tempo: até o Access tem estas coisas que o pessoal da
> > > > MySQL acha que é dispensável).
> > > >
> > > > Apesar de todos os "problemas sérios" que tu citou Luis, infelizmente
> > > > aquela "coisa" do MS Access consegue se sair bem. É uma anarquia que
> > > > funciona. No caso, este sistema em Access que estamos falando, roda em
> > > > cerca de 50 máquinas e nunca teve uma falha grave. Recentemente a
> > > > empresa onde trabalho está desenvolvendo um outro software que roda
> > > > pela Web, gerenciando uma base de dados em MS Access também, e neste
> > > > eles dizem que querem ter mais de 1000 usuários... Sinceramente não
> > > > acredito que o Access vai aguentar estas carga toda, mas estou de
> > > > "olho" na solução deles (apenas para constar, apesar da empresa onde
> > > > eu trabalho ter soluções MS, eu só trabalho com software livre, sendo
> > > > que o mais perto que cheguei de uma solução usando MS, foi a de alguns
> > > > scripts em Perl que replicam dados do Access para o MySQL).
> > > >
> > > > SDS,
> > > >
> > > > Luciano
> > > >
> > > >
> > > > luiz.carvalho em orbitall.com.br escreveu:
> > > >
> > > >
> > > > > > > Luciano Giordani Bassani wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > Er Galvão Abbott wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > > O MS Access, em termos de performance, não é tão ruím. Já quebrei a
> > > > > > > cabeça tentando convencer meu chefe para trocar de backend em umas
> > > > > > > aplicações que temos, falando em relação da performance e no fim tive
> > > > > > > que enfiar "meu rabo entre as pernas". Consultas no Access são
> > > > > > > extremamente mais velozes, se comparados com o PostgreSQL ou MySQL, ou
> > > > > > > até mesmo o MS SQL Server. É duro, mas é verdade.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > Hmmm... Eu já desenvolvi uma vez uma aplicação Perl + MS Access +
> > > > > > Windows 2000 Server e a performance era terrível, especialmente com
> > > > > > conexões simultâneas. Só acredito que o Access seja mais rápido do que o
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > > Postgres (não vou nem falar em mySQL porque não considero ele um banco
> > > > > > de dados) com um benchmark bem feitinho.
> > > > > >
> > > > > >
> > > > > >
> > > > > Não é preciso fazer benchmark, Galvão.
> > > > >
> > > > > Pense que um banco access não sofre gargalos que vão de acesso á
> > > > > rede (é um arquivo em disco, nada mais!) até gerenciamento de
> > > > > índices bitmap (é um arquivo em disco, nada mais!).
> > > > >
> > > > > O "dark side" em usar Access é que ele tem todas as desvantagens de
> > > > > utilizar arquivos como banco de dados (essa discussão estava rolando
> > > > > aqui mesmo, uns dias atrás) sobre uma "capa" de (des)controle com
> > > > > aparência de banco de dados relacional.
> > > > >
> > > > > Em outras palavras: ele é um arquivo de dados, com problemas sérios
> > > > > de concorência, de acesso simulâneo, sem locks no nível de linha de
> > > > > dados, sem indexação satisfatória, sem comunicação pela rede. Mas
> > > > > ele tem todas as restrições que adotamos para ter essas coisas em um
> > > > > banco de dados sério: não podemos mexer com os "internals" do
> > > > > access, nem saber como ele atende as requisições que fazemos a ele.
> > > > >
> > > > > Não acredito que um banco de dados "sério" possa ser mais rápido do
> > > > > que um arquivo access, mas tenho certeza de que o custo que se paga
> > > > > para usar arquivos access, em dor-de-cabeça e chateação, não vale o
> > > > > ganho em performance.
> > > > >
> > > > > Na minha opinião, o problema não é realmente performance, mas amor
> > > > > aos dados, e amor aos seus finais-de-semana.
> > > > >
> > > > > Putamplexos!
> > > > > --
> > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > > Luis Campos de Carvalho Engenheiro de Sistemas Web
> > > > > Engenharia de Software Ltda.
> > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > > > >
> > > > > _______________________________________________
> > > > > Cascavel-pm mailing list
> > > > > Cascavel-pm em pm.org
> > > > > http://mail.pm.org/mailman/listinfo/cascavel-pm
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > ------------------------------------------------------------------------
> > > >
> > > > _______________________________________________
> > > > Cascavel-pm mailing list
> > > > Cascavel-pm em pm.org
> > > > http://mail.pm.org/mailman/listinfo/cascavel-pm
> > > >
> > > >
> > > _______________________________________________
> > > Cascavel-pm mailing list
> > > Cascavel-pm em pm.org
> > > http://mail.pm.org/mailman/listinfo/cascavel-pm
> > >
> > >
> > >
> _______________________________________________
> Cascavel-pm mailing list
> Cascavel-pm em pm.org
> http://mail.pm.org/mailman/listinfo/cascavel-pm
Mais detalhes sobre a lista de discussão Cascavel-pm