T� bom.... ASCII em 1 segundo, e SQL em 10s, ou voc� errou, ou
tera que avisar o urgentemente para o yahoo.com ( usa o MySQL )
mudar sua base de dados com 200GB e uma grande rede
complexa de servidores com milhares de acessos simultaneos
para um unico micro isolado ( o melhor que ASCII faz ) com seu
banco de dados de 200GB em um TXT (piada). O MySQL trabalha
em conjudo com muitas maquinas diferente de ASCII.
N�o quero mais ficar escrevendo sempre a mesma coisa, e
pessoas metidas a "programadores" ficarem falando ***** , AS
VEZES ME PERGUNTO: Como � possivel uma pessoa ser t�o
******* ?? ser� que estes kras v�o sair um dia da lista (eeee...) ??
QUANDO V�O ENTENDER "COMPUTADORES, HOJE, N�O
PODEM TRABALHAR SOZINHOS"??
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
ATEN��O: Eu sei que n�o � "SQL" mais coloco assim para n�o
ter que escrever : MySQL, MSQL, PostgreSQL....
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
________________________
Adriano A. Meirelles
[EMAIL PROTECTED]
On 10 Jul 00, at 10:12, Charles Roberto Pilger wrote:
> Ol�
>
> S� para fins de corre��o:
>
> On 8 Jul 2000, at 15:21, [EMAIL PROTECTED] wrote:
> > nos anos 80 se usavam ASCII pela �nica vantagem "seu
> > tamanho" em programas
>
> Desculpe, mas arquivos em modo ASCII sempre se usou para
> transporte de dados. Afinal, antes de termos SGBDs conversando
> entre si t�nhamos que fazer os programas em Cobol acessarem os
> dados de outros programas escritos em C (por exemplo) e vice-
> versa. Nesse ponto o ASCII era o padr�o para isso.
>
> E quanto ao ASCII ser bom ou n�o para armazenamento, s� quero
> lembrar mais uma vez: h� casos em que ele � melhor. Quando
> voc� tem um servidor web em uma m�quina e um servidor SQL em
> outra (na verdade, um bando de servidores SQL, em v�rias
> m�quinas diferentes), o tempo de acesso � base de dados �
> aumentado consideravelmente. Assim, manter uma replica��o em
> modo ASCII dos seus dados no seu servidor, atualizadas de forma
> din�mica, acaba resultando num tempo de espera menor para o
> usu�rio. Poderia ser colocado um servidor SQL na mesma
> m�quina? Sim, poderia, mas n�o foi feito: o pessoal da
> administra��o de dados j� foi escalado para fazer isso mas esse
> job est� nas "ten tousands priorities".
>
> Ou seja, em condi��es de trabalho dessas, algu�m poderia me
> indicar uma solu��o melhor que usar o ASCII? DBM � algo
> improv�vel, j� que hoje o servidor � Solaris, e amanh� pode ser
> Windows NT. N�o, n�o vai ser mudado a plataforma, o que
> acontece � que a universidade "estimula" o desenvolvimento de
> solu��es que n�o fiquem preso a uma plataforma espec�fica.
> Nesse ponto o ASCII � uma solu��o �tima, justamente por n�o ser
> preso a sistema algum, por ser um formato limpo.
>
> E bem ou mal o Perl � extremamente r�pido para maniplar
> arquivos ASCII. Fizemos testes para ver como ele era manipulando
> um arquivo com mais de 10 Mb e ele abriu o arquivo, fez a busca e
> retornou a resposta em emnos de 1 segundo. Procurando pelo
> mesmo dado acessando a base de dados em SQL o tempo de
> resosta foi de quase 10 segundos. Talvez com o servidor SQL
> estando na mesma m�quina esse resultado seja diferente, mas
> nas condi��es atuais de trabalho dizer que acessar bases de
> dados em um servidor SQL � melhor do que acessar arquivos em
> modo ASCII por ser uma tecnologia melhor � simplificar a quest�o.
>
> []'s
>
>
> Charles Roberto Pilger ([EMAIL PROTECTED])
> Work: http://www.unisinos.br Personal: http://CharlesPilger.i.am
> ICQ: 636464 - WCQ: 14074 (http://www.wcq.com.br)
> http://www.mrweb.com.br/perl/
> >>No site da lista, voce tera tudo sobre PERL,
> >>LINUX, PHP, ASP e informacoes, cadastramento
> >>e descadastramento da Lista.
>
>
>
>
>
http://www.mrweb.com.br/perl/
�������������>No site da lista, voce tera tudo sobre PERL,
>>LINUX, PHP, ASP e informacoes, cadastramento
>>e descadastramento da Lista.
������������==
