MS SQL - Migração do MySQL em um webapp legado

Question

Eu gostaria de migrar o banco de dados de um aplicativo legado web a partir do SQL Server para MySQL. Quais são as limitações do MySQL que eu devo olhar para fora? E o que todos os itens seria parte de uma lista abrangente antes de saltar para realmente modificar o código?

Answer 1

A primeira coisa que gostaria de verificar se os tipos de dados - a definição exata de tipos de dados varia de banco de dados para banco de dados. Gostaria de criar uma lista de mapeamento que tellme que mapear cada um dos tipos de dados para. Isso vai ajudar na construção de novas tabelas. Também gostaria de verificar a existência de tabelas de dados ou colunas que não estão sendo usados ??agora. Nenhum ponto em migrá-los. Faça o mesmo com as funções, trabalho, sps, etc. Agora é a hora de limpar o lixo.

Como você está acessando os dados através sps ou consultas dinâmicas do banco de dados? Verifique cada consulta, executando-aganst um novo banco de dados dev e com certeza fazer eles ainda trabalho. Novamente, há diferenças entre a forma como os dois sabores de trabalho SQL. Eu não usei o meu sql, então eu não tenho certeza do que alguns dos pontos de falha comuns são. Enquanto você está nisso, você pode querer cronometrar novas consultas e ver se eles podem ser otimizados. Otimização também varia de banco de dados para banco de dados e, enquanto você está nisso, há provavelmente algumas consultas com fraco desempenho agora que você pode corrigir, como parte da migração.

funções definidas pelo utilizador terá de ser encarado como bem. Não se esqueça estes se você está fazendo isso.

Não se esqueça trabalhos programados, estes terão de ser checkd e recriado em myslq também.

Você importar quaisquer dados ona programação regular? Todas as importações terá de ser reescrito.

chave de tudo é a utilização de um banco de dados de teste e testar, testar e testar. Teste tudo, especialmente trimestral ou relatórios anuais ou trabalhos que você pode esquecer.

Outra coisa que você quer fazer é fazer tudo por meio de scripts que são versão controlada. Não mova a produção até que você pode executar todos os scripts em ordem sobre dev sem falhas.

Answer 2

Uma coisa que eu esqueci, verifique se o banco de dados dev você está executando a migração a partir de (o banco de dados SQL Server) é atualizado desde a produção imediatamente antes de cada teste. Odeio ter algo falhar em prod porque você estavam testando contra registros desatualizados.

Answer 3

O seu código de cliente é quase certo que será a parte mais complexa para modificar. A menos que a sua aplicação tem um conjunto de testes de alta qualidade, você vai acabar tendo que fazer um monte de testes. Você não pode confiar em qualquer coisa trabalhando os mesmos, até mesmo coisas que você pode esperar.

Sim, as coisas no próprio banco de dados terá de mudar, mas o código do cliente é onde a ação principal é, ele terá montes de trabalho e testes rigorosos.

Esqueça migrar os dados, que é a última coisa que deve estar em sua mente; o esquema do banco provavelmente pode ser convertido sem muita dificuldade; outros objetos de banco de dados (SPs, vistas, etc.) poderia causar problemas, mas o código do cliente é onde o foco dos problemas será.

Quase todos os rotina que executa uma consulta de banco de dados terá de ser mudado, mas absolutamente todos eles terão de ser testados. Este será trivial.

Atualmente, estou olhando para a migração do banco de dados principal de nosso aplicativo do MySQL 4.1 a 5, que é muito menos de uma diferença, mas ainda será uma tarefa muito, muito grande.