DE VB6 PARA WEB
Bom dia!
Desenvolvi um pequeno sistema que faz cálculos tributários com base em arquivos de texto importados. Agora pretendo desenvolver a versão Web, em PHP.
Na versão VB6, o computador e banco de dados (MySQL) são bastante exigidos. Cada txt tem em média 50.000 linhas. Depois da importação, são feitos vários cálculos com SQL complexas. Uma das mais demoradas é onde são verificados os registros duplicados. Toda vez que importo um txt, é necessário verificar se já existem nos que á foram importados anteriormente.
Hoje uso uma máquina virtual windows XP para rodar o programa e o banco de dados fica em outra máquina virtual Linux. Ambas foram configuradas para usar 1 processador do notebook, que é o host (i7 2620M - 2.7 Ghz)
O processo todo tem três etapas:
- importação
- checagem dos repetidos
- cálculos
E leva cerca de 2 minutos, por txt, para ser finalizado. Eu não uso stored procedures.
Resumindo:
Eu não faço ideia da performance em um servidor Web, pois ainda não comecei o projeto. Vcs acham que posso rodar isso tranquilamente em hospedagens web?
Pretendo hospedar na KingHost. Mas não diz quanto é o processamento.
Será que stored procedure é uma boa? Nunca implementei isso na minha vida, mas dizem que toda o processamento da SQL fica no servidor. Porém, todas as inserções no meu sistema VB6, uso um INSERT INTO que faz tudo de uma vez só. Eu achei a performance mto boa.
é isso.
Abs.
Desenvolvi um pequeno sistema que faz cálculos tributários com base em arquivos de texto importados. Agora pretendo desenvolver a versão Web, em PHP.
Na versão VB6, o computador e banco de dados (MySQL) são bastante exigidos. Cada txt tem em média 50.000 linhas. Depois da importação, são feitos vários cálculos com SQL complexas. Uma das mais demoradas é onde são verificados os registros duplicados. Toda vez que importo um txt, é necessário verificar se já existem nos que á foram importados anteriormente.
Hoje uso uma máquina virtual windows XP para rodar o programa e o banco de dados fica em outra máquina virtual Linux. Ambas foram configuradas para usar 1 processador do notebook, que é o host (i7 2620M - 2.7 Ghz)
O processo todo tem três etapas:
- importação
- checagem dos repetidos
- cálculos
E leva cerca de 2 minutos, por txt, para ser finalizado. Eu não uso stored procedures.
Resumindo:
Eu não faço ideia da performance em um servidor Web, pois ainda não comecei o projeto. Vcs acham que posso rodar isso tranquilamente em hospedagens web?
Pretendo hospedar na KingHost. Mas não diz quanto é o processamento.
Será que stored procedure é uma boa? Nunca implementei isso na minha vida, mas dizem que toda o processamento da SQL fica no servidor. Porém, todas as inserções no meu sistema VB6, uso um INSERT INTO que faz tudo de uma vez só. Eu achei a performance mto boa.
é isso.
Abs.
São vários pontos aà à serem observados:
- Se suas tabelas no banco de dados possuem chave primária, você não precisaria em teoria verificar se o registro existe ou não, basta tentar a inserção com os dados do TXT, se já existir, vai dar erro e se necessário então execute um update do registro na tabela com os dados do registro no TXT, só aà já mataria um processo redundante
- Não sei onde você pegou essa informação de que [Ô]processamento SQL fica no servidor e inserções no VB6[Ô], mas com certeza você está confundindo. A explicação:
Cada comando SQL é enviado ao banco de dados pelo driver ODBC do MySQL. Comandos de inserção, também são queries. Logo, ao executar o comando, o banco de dados no servidor, recebe os dados e os processa. Logo isso também é tarefa do servidor. Então, no momento em que você chamou o [Ô]execute[Ô], os dados já estão sob responsabilidade do serviço MySQL no servidor e a tarefa do client(o seu programa) acabou.
O seu [Ô]gargalo[Ô] é realmente essa verificação de duplicidade que é totalmente desnecessária, visto que isso é tarefa do banco de dados. Ao inserir, os dados são comparados com todos os registros da tabela recursivamente. Em caso de duplicação de dados dessa chave(que podem ser vários campos), o banco de dados deve lançar um erro para o client(o seu programa) e então você decide o que deve ser feito. Muitas vezes é simplesmente ignorado, mas é possÃvel que você queira atualizar o registro em caso de duplicidade, logo, usar o comando UPDATE. Mas, novamente, isso depende do que você quer que seja feito.
Quanto ao poder de processamento do servidor, isso com certeza absoluta não será problema. Mesmo os provedores de serviço mais simples, oferecem um processamento muito maior que o seu servidor atual fornece. O seu problema vai ser outro:
Não sei como você quer fazer o recebimento desses dados no servidor. Se for uma aplicação no server(PHP, ASP.NET, ASP, Python...), o arquivo terá que ser submetido, ou seja, upload dele para que a sua aplicação no server possa ler. Se for uma aplicação client, que você já tem pronto, então a coisa facilita, visto que você já está usando uma inserção em lote e teoricamente bastaria mudar a string de conexão no seu programa. O caso é, como já citei, essa verificação de duplicidade redundante. Você teria que refazer essa parte para poder trabalhar de forma eficiente no client e evitar um [Ô]vai e vem[Ô] de consultas SQL o que faria com que a performance caia drasticamente.
- Se suas tabelas no banco de dados possuem chave primária, você não precisaria em teoria verificar se o registro existe ou não, basta tentar a inserção com os dados do TXT, se já existir, vai dar erro e se necessário então execute um update do registro na tabela com os dados do registro no TXT, só aà já mataria um processo redundante
- Não sei onde você pegou essa informação de que [Ô]processamento SQL fica no servidor e inserções no VB6[Ô], mas com certeza você está confundindo. A explicação:
Cada comando SQL é enviado ao banco de dados pelo driver ODBC do MySQL. Comandos de inserção, também são queries. Logo, ao executar o comando, o banco de dados no servidor, recebe os dados e os processa. Logo isso também é tarefa do servidor. Então, no momento em que você chamou o [Ô]execute[Ô], os dados já estão sob responsabilidade do serviço MySQL no servidor e a tarefa do client(o seu programa) acabou.
O seu [Ô]gargalo[Ô] é realmente essa verificação de duplicidade que é totalmente desnecessária, visto que isso é tarefa do banco de dados. Ao inserir, os dados são comparados com todos os registros da tabela recursivamente. Em caso de duplicação de dados dessa chave(que podem ser vários campos), o banco de dados deve lançar um erro para o client(o seu programa) e então você decide o que deve ser feito. Muitas vezes é simplesmente ignorado, mas é possÃvel que você queira atualizar o registro em caso de duplicidade, logo, usar o comando UPDATE. Mas, novamente, isso depende do que você quer que seja feito.
Quanto ao poder de processamento do servidor, isso com certeza absoluta não será problema. Mesmo os provedores de serviço mais simples, oferecem um processamento muito maior que o seu servidor atual fornece. O seu problema vai ser outro:
Não sei como você quer fazer o recebimento desses dados no servidor. Se for uma aplicação no server(PHP, ASP.NET, ASP, Python...), o arquivo terá que ser submetido, ou seja, upload dele para que a sua aplicação no server possa ler. Se for uma aplicação client, que você já tem pronto, então a coisa facilita, visto que você já está usando uma inserção em lote e teoricamente bastaria mudar a string de conexão no seu programa. O caso é, como já citei, essa verificação de duplicidade redundante. Você teria que refazer essa parte para poder trabalhar de forma eficiente no client e evitar um [Ô]vai e vem[Ô] de consultas SQL o que faria com que a performance caia drasticamente.
Boa tarde!
Creio que vc tenha me entendido errado. O que eu quis dizer é que já ouvi dizer que com stored procedures, a carga de processamento fica 100% no servidor. E que no meu projeto uso INSERT INTO, e não stored procedures. Como a performance ficou muito boa, eu imaginava que o processamento de uma forma ou de outra, era enviado para o banco de dados. Depois que vc esclareceu que a partir do execute o processamento passa para o servidor, as coisas ficaram mais claras. Obrigado!
Em relação a verificação de duplicidade, eu faço tudo via SQL. Primeiro o sistema importa os txts para tabelas temporárias. Depois comparo os dados que estão nas tabelas temporárias com os que já existem nas tabelas definitivas.
Os campos envolvidos no sistema são: nome, salario, data e codigo. Podem existir nomes, salários, datas e códigos repetidos. Só não pode existir um recordset composto de nome, salário, data e código iguais. Ex:
--- Isto é considerada uma duplicidade
flavio - 1.000,00 - 25/12/2015 - 635
flavio - 1.000,00 - 25/12/2015 - 635
--- e isto não é
flavio - 1.000,00 - 25/12/2015 - 635
flavio - 1.000,00 - 25/12/2015 - 634
é necessário verificar se já não existem as linhas do txt que está sendo importado e não somente linhas repetidas no txt. Ou seja, se já existem 900.000 linhas importadas, e eu estou importando 50.000 linhas de um txt, é necessário saber se alguma destas 50.000 linhas já não existe entre as 900.000 linhas.
Infelizmente não posso usar as chaves primárias, pois duplicidade neste caso é uma ocorrência de 4 campos iguais.
Se o MySQL tivesse a função MINUS, resolveria os meus problemas. Mas tem o LEFT JOIN, que parece ser equivalente. A performance ficou muito boa.
A checagem de duplicados e inserção no banco (dos registros únicos), faço tudo em uma mesma SQL usando INSERT INTO SELECT + LEFT JOIN.
A dúvida era saber se os provedores iriam me impedir de usar este sistema, pois usa muito processamento. Bom, muito é relativo. Para cada arquivo de 50.000 linhas, o sistema leva cerca de (até) 2 minutos para importar os txts, checar os itens duplicados e importar somente os inéditos e fazer os cálculos. Geralmente são feitos 5 ou 6 txts por vez. O que dá de 10 à 12 minutos e entre 70 e 100% de uso do processador.
Creio que vc tenha me entendido errado. O que eu quis dizer é que já ouvi dizer que com stored procedures, a carga de processamento fica 100% no servidor. E que no meu projeto uso INSERT INTO, e não stored procedures. Como a performance ficou muito boa, eu imaginava que o processamento de uma forma ou de outra, era enviado para o banco de dados. Depois que vc esclareceu que a partir do execute o processamento passa para o servidor, as coisas ficaram mais claras. Obrigado!
Em relação a verificação de duplicidade, eu faço tudo via SQL. Primeiro o sistema importa os txts para tabelas temporárias. Depois comparo os dados que estão nas tabelas temporárias com os que já existem nas tabelas definitivas.
Os campos envolvidos no sistema são: nome, salario, data e codigo. Podem existir nomes, salários, datas e códigos repetidos. Só não pode existir um recordset composto de nome, salário, data e código iguais. Ex:
--- Isto é considerada uma duplicidade
flavio - 1.000,00 - 25/12/2015 - 635
flavio - 1.000,00 - 25/12/2015 - 635
--- e isto não é
flavio - 1.000,00 - 25/12/2015 - 635
flavio - 1.000,00 - 25/12/2015 - 634
é necessário verificar se já não existem as linhas do txt que está sendo importado e não somente linhas repetidas no txt. Ou seja, se já existem 900.000 linhas importadas, e eu estou importando 50.000 linhas de um txt, é necessário saber se alguma destas 50.000 linhas já não existe entre as 900.000 linhas.
Infelizmente não posso usar as chaves primárias, pois duplicidade neste caso é uma ocorrência de 4 campos iguais.
Se o MySQL tivesse a função MINUS, resolveria os meus problemas. Mas tem o LEFT JOIN, que parece ser equivalente. A performance ficou muito boa.
A checagem de duplicados e inserção no banco (dos registros únicos), faço tudo em uma mesma SQL usando INSERT INTO SELECT + LEFT JOIN.
A dúvida era saber se os provedores iriam me impedir de usar este sistema, pois usa muito processamento. Bom, muito é relativo. Para cada arquivo de 50.000 linhas, o sistema leva cerca de (até) 2 minutos para importar os txts, checar os itens duplicados e importar somente os inéditos e fazer os cálculos. Geralmente são feitos 5 ou 6 txts por vez. O que dá de 10 à 12 minutos e entre 70 e 100% de uso do processador.
Faça seu login para responder