ActiveDelphi

[infoteck]

Caros colegas, tenho uma aplicação com bd paradox rodando perfeitamente há mais de 14 anos em mais de 20 estações simultâneas porém via TS pelo peso do banco, nao tenho nenhuma dor-de-cabeça, porém, para se atualizar, quero migrar para o Firebird e estarei utilizando os componentes da DbExpress, minha dúvida é o seguinte, como ainda não vou migrar totalmente isso ocorrerá em etapas, vou ir migrando aos poucos, ou seja, gostaria de saber se corro o risco de ter algum problema ou situação adversa se eu trabalhar no meu sistema com uma parte em paradox e outra em firebird, visto que não sou especialista em firebird e tenho apenas algumas consultas em sql.

[builder_rs]

Olá, passei por uma situação parecida como a sua, com banco de dados em xBase, aplicação rodando na época a quase 16 anos e em torno de 18 estações. No período do xBase, iniciamos no Xenix (Unix) e depois para DOS, Windows 3.x a 9.x. A primeira migração ocorreu em meados de 2001/2002 para linux, mas ainda usando xBase. Fizemos uma aposta no kylix que não vingou, então ficamos rodando a aplicação via emulação de terminal. No linux, tivemos velocidade e estabilidade.

A migração para o Firebird foi complexa, pois havia uma quebra de paradigma muito grande do xBase para SQL.

Em xBase abre-se a tabela inteira e velocidade não é um problema, apenas um desperdício de recursos (nenhum usuário quer olhar os 300.000 registros e, mesmo que quisesse, levaria dias).

Em SQL, recupera-se somente os registros que o usuário realmente vai utilizar, poupando recursos (tráfego de rede, memória). Quando se ignora esta regra, ganha de brinde uma lentidão no sistema.

Como aconteceu a migração:

1-A aplicação antiga estava funcionando, então não era algo urgente, crítico (havia tempo para planejar). Outras aplicações menores e novas tarefas também foram incluídas no projeto - Não era uma simples migração porque também tinha unificação de sistemas legados, planilhas, etc. (a ordem era unificar, simplificar, automatizar);

2-A aplicação antiga tinha várias limitações (a famosa dívida técnica) e coisas que podiam ser melhoradas. Tudo o que era uma pedra no sapato foi resolvido na nova aplicação ou seja, não migramos só por migrar, havia um ganho de funcionalidades considerável;

3-Os usuários testaram a nova aplicação, apresentaram sugestões e apontaram os defeitos. Tudo foi resolvido para que não houvesse saudades do ambiente antigo. A regra era: O sistema novo deverá fazer tudo o que o antigo faz, de forma no mínimo igual, mas de preferência melhor;

4-Os dados (aqui foi o pulo do gato) do sistema antigo foram importados (várias vezes, totalmente), onde se faziam os ajustes nas tabelas no novo sistema, as informações eram checadas, relatórios eram emitidos e confrontados com o sistema anterior (averiguar se mostravam os mesmos resultados). A performance , a usabilidade, os novos recursos do sistema eram testadas pelos usuários. As rotinas de backup/restore e a própria documentação de instalação/contenção de desastres também foram elaboradas e testadas;

5-Os usuários foram treinados, um por um. Isto foi necessário para evitar situações de pedidos de treinamento após a migração, já que sua atenção e tempo estarão totalmente voltados para os problemas que aparecerem (e vão aparecer). Alguns dias foram selecionados para a utilização dos dois sistemas (antigo e novo), registrando/digitando a mesma informação em cada um para validar a entrada, a gravação e os relatórios (foram dias de caça aos bugs);

6-O dia D (da migração) é marcado com antecedência, sendo este prazo utilizado para os últimos treinamentos e ajustes no sistema. É importante que a equipe esteja ciente que o dia irá terminar, será feita a última importação de dados e no dia seguinte, já inicia com o novo sistema.

7-A data do dia D foi definida escolhendo-se o período de menor uso do sistema e que, eventual ajustes/paradas não iriam comprometer os prazos de entrega de informações (evitar juros, multas, insatisfações dos clientes, etc.)

Resumindo:

- Migre se houverem boas vantagens (não por modismo). É muito trabalho e um risco alto de problemas;
- Treine os usuários e ouça as solicitações (para evitar boicotes ao novo sistema);
- Faça sempre a importação 100% dos dados do antigo para o novo. Os testes serão mais reais, com a mesma carga de trabalho;
- O sistema novo deverá fazer tudo igual ou melhor que o antigo (nada de isto esta no novo e aquilo no antigo, é contra produtivo e um pé no saco para o usuário);
- Tenha a aprovação da alta direção da empresa (de seus clientes), afinal na sua visão você pode achar que está entregando um carro e o cliente vê como uma canoa furada. Mostre o que vão ganhar com a migração (eles devem desejar a migração);
- Conserte e ajuste tudo para ser resolvido na migração. Se deixar para depois da migração (com o trem andando), vai trabalhar dobrado (precisará de todo o tempo e velocidade para resolver os problemas que não foram detectados antes);
- Importantíssimo: Domine 100% o novo ambiente (linguagem, sistema operacional, IDE, Firebird, etc.) antes da migração, porque o tempo para estudar para saber como é que se faz será uma "espécie extinta ou quase", e tudo será urgente/pra ontem.


Att.

Anderson.

[infoteck]

Olá amigo, muito obrigado por compartilhar sua experiência, como eu disse realmente o que me motivou a mudar foi a facilidade do banco e em trabalhar com transações, coisa que não faço no Paradox, embora ontem brincando um pouco pude perceber que é possível através de uma table, um provider e uma query trabalhar e depois enviar a informação para o banco através da ApplyUpdates, acho que isso já resolve muito as questões de que quando um usuario faz uma venda a energia seja interrompida sem o processo estar totalmente completado, so tenho duvida de como trabalhar com baixa de estoque em um ambiente onde não estou direto no banco e sim em um cache, o que pode me dizer sobre isso ?

Abraço e mais uma vez muito obrigado.