<!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">
Na verdade eu creio que EU tenho mais dores de cabe&ccedil;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&atilde;o coisas da vida. A gente s&oacute;
aprende "botando a m&atilde;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&atilde;o ter usado o Firebird em nenhuma solu&ccedil;&atilde;o ainda),
mas infelizmente uma migra&ccedil;&atilde;o destas tem um custo muito alto e o
cliente est&aacute; satisfeito com o que ele tem. Eu &eacute; que sofro para
implementar "gambiarras" para as faltas de store procedures, triggers,
etc no MySQL (em tempo: at&eacute; o Access tem estas coisas que o pessoal da
MySQL acha que &eacute; dispens&aacute;vel).<br>
<br>
Apesar de todos os "problemas s&eacute;rios" que tu citou Luis, infelizmente
aquela "coisa" do MS Access consegue se sair bem. &Eacute; uma anarquia que
funciona. No caso, este sistema em Access que estamos falando, roda em
cerca de 50 m&aacute;quinas e nunca teve uma falha grave. Recentemente a
empresa onde trabalho est&aacute; desenvolvendo um outro software que roda
pela Web, gerenciando uma base de dados em MS Access tamb&eacute;m, e neste
eles dizem que querem ter mais de 1000 usu&aacute;rios... Sinceramente n&atilde;o
acredito que o Access vai aguentar estas carga toda, mas estou de
"olho" na solu&ccedil;&atilde;o deles (apenas para constar, apesar da empresa onde eu
trabalho ter solu&ccedil;&otilde;es MS, eu s&oacute; trabalho com software livre, sendo que
o mais perto que cheguei de uma solu&ccedil;&atilde;o usando MS, foi a de alguns
scripts em Perl que replicam dados do Access para o MySQL).<br>
<br>
SDS,<br>
<br>
Luciano<br>
<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:luiz.carvalho@orbitall.com.br">luiz.carvalho@orbitall.com.br</a> escreveu:
<blockquote
 cite="midOFFD8EC05A.6244FD9C-ON0325704C.005112B6-8325704C.00525637@orbitall.corp"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">Luciano Giordani Bassani wrote:
      </pre>
    </blockquote>
    <pre wrap="">Er Galv&atilde;o Abbott wrote:

    </pre>
    <blockquote type="cite">
      <pre wrap="">O MS Access, em termos de performance, n&atilde;o &eacute; t&atilde;o ru&iacute;m. J&aacute; quebrei a 
cabe&ccedil;a tentando convencer meu chefe para trocar de backend em umas 
aplica&ccedil;&otilde;es que temos, falando em rela&ccedil;&atilde;o da performance e no fim tive 
que enfiar "meu rabo entre as pernas". Consultas no Access s&atilde;o 
extremamente mais velozes, se comparados com o PostgreSQL ou MySQL, ou 
at&eacute; mesmo o MS SQL Server. &Eacute; duro, mas &eacute; verdade.


      </pre>
    </blockquote>
    <pre wrap="">Hmmm... Eu j&aacute; desenvolvi uma vez uma aplica&ccedil;&atilde;o Perl + MS Access + 
Windows 2000 Server e a performance era terr&iacute;vel, especialmente com 
conex&otilde;es simult&acirc;neas. S&oacute; acredito que o Access seja mais r&aacute;pido do que o 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
  <blockquote type="cite">
    <pre wrap="">Postgres (n&atilde;o vou nem falar em mySQL porque n&atilde;o considero ele um banco 
de dados) com um benchmark bem feitinho.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  N&atilde;o &eacute; preciso fazer benchmark, Galv&atilde;o.

  Pense que um banco access n&atilde;o sofre gargalos que v&atilde;o de acesso &aacute;
  rede (&eacute; um arquivo em disco, nada mais!) at&eacute; gerenciamento de
  &iacute;ndices bitmap (&eacute; um arquivo em disco, nada mais!).

  O "dark side" em usar Access &eacute; que ele tem todas as desvantagens de
  utilizar arquivos como banco de dados (essa discuss&atilde;o estava rolando
  aqui mesmo, uns dias atr&aacute;s) sobre uma "capa" de (des)controle com
  apar&ecirc;ncia de banco de dados relacional.

  Em outras palavras: ele &eacute; um arquivo de dados, com problemas s&eacute;rios
  de concor&ecirc;ncia, de acesso simul&acirc;neo, sem locks no n&iacute;vel de linha de
  dados, sem indexa&ccedil;&atilde;o satisfat&oacute;ria, sem comunica&ccedil;&atilde;o pela rede. Mas
  ele tem todas as restri&ccedil;&otilde;es que adotamos para ter essas coisas em um
  banco de dados s&eacute;rio: n&atilde;o podemos mexer com os "internals" do
  access, nem saber como ele atende as requisi&ccedil;&otilde;es que fazemos a ele.

  N&atilde;o acredito que um banco de dados "s&eacute;rio" possa ser mais r&aacute;pido do
  que um arquivo access, mas tenho certeza de que o custo que se paga
  para usar arquivos access, em dor-de-cabe&ccedil;a e chatea&ccedil;&atilde;o, n&atilde;o vale o
  ganho em performance.

  Na minha opini&atilde;o, o problema n&atilde;o &eacute; 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
<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>