[Cascavel-pm] Linux+Perl+MSAccess
João Gabriel
jamorreu em gmail.com
Quinta Julho 28 13:42:15 PDT 2005
Realmente, se o MySQL tiver que ser usado como banco de dados para
coisa complexas creio que não seria muito viavel em termos de
recursos...
Agora se for só gravar, ler e editar informações, ele quebra um santo
galho pra mim e não dá pau... (no cgiclube.net tem uma tabela com
pouco mais de 480.000 iténs, sendo que recebe por dia algo como 60.000
cadastros e tá rodando as mil maravilhas).
Acho que sempre vai existir prós e contras de cada banco de dados,
porém, deve avaliar o que você precisa e escolher o mais adequado
(ficar dando "paulada" só porque um banco de dados não atendem as suas
necessidades não é correto..).
--
[]'s
João Gabriel
CGiClube.net - www.cgiclube.net
Vitória Perl Mongers - vitoria.pm.org
Em 28/07/05, Luciano Giordani Bassani<lgbassani em terra.com.br> escreveu:
> Eu já levei... Mas mesmo assim ainda existe algumas pequenas soluções que
> eu opto por mysql, mas JAMAIS irei usar ele novamente em um sistema mais
> complexo, pq sou preguiçoso mesmo e não gosto de ficar escrevendo código e
> mais código para simular uma simples view... Ou ter que ficar fazendo
> scritps que rodam via crontab, pq a meleca não tem um eca de uma trigger
> para atualizar aquela minha tabelinha estática de estísticas... Entre outros
> exemplos.
>
> Ainda assim, tem algumas soluções simples, com poucas inclusões e mais
> selects simples que eu uso o mysql. Eu falo isso pq comecei a desenvolver
> outro projeto com o mysql (www.eventor.com.br) e teve uma hora que fiquei
> revoltado e testei o PostgreSQL... Que beleza! Isso sim é que é botar o
> Banco de dados trabalhar para mim! Apesar que nem ele eu acho perfeito...
> Por exemplo, até pouco tempo dar um alter table não era algo simples.
>
>
> Cara, vcs não tem noção das piadinhas que tive que ouvir de meus colegas
> quando algum programador de MS Access me dizia: mas pq tu não usou uma view
> aí nesta tua query, ao invés de perder tanto tempo neste código? E eu lá,
> todo envergonhado dizendo: é que esta versão ainda não tem view, mas na
> x.y.z que vai sair não sei quando vai ter... Bah! Horrível...
>
> Mas vc tem razão sobre isso de analizar bem o que vc quer, para escolher a
> melhor opção. Hoje em dia eu faço isso, e uso tanto PostgreSQL e MySQL, às
> vezes em arquivo txt, mesmo. Tudo depende do que eu quero fazer e onde quero
> chegar. Só que quando eu comecei a coisa não era tão simples assim. A
> informação era bem mais escassa e infelizmente não é tão simples assim
> migrar algo.
>
>
> SDS,
>
> Luciano
>
>
>
>
> Rodolfo Sikora escreveu:
> 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
>
> _______________________________________________
> 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