[Cascavel-pm] Linux+Perl+MSAccess

"Er Galvão Abbott - PortoAlegre.pm" galvao em perl.org.br
Quinta Julho 28 09:06:59 PDT 2005


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
>


Mais detalhes sobre a lista de discussão Cascavel-pm