MS SQL -Legacy WebApp에서 MySQL 마이그레이션

Question

레거시 웹 앱의 데이터베이스를 SQL Server에서 MySQL로 마이그레이션하고 싶습니다. 내가 찾아야 할 MySQL의 한계는 무엇입니까? 그리고 실제로 코드를 수정하기 전에 포괄적 인 체크리스트의 일부는 무엇입니까?

Answer 1

가장 먼저 확인해야 할 것은 데이터 유형입니다. 데이터 유형의 정확한 정의는 데이터베이스마다 다릅니다. 각 데이터 유형을 매핑 할 내용을 알려주는 매핑 목록을 작성합니다. 새로운 테이블을 만드는 데 도움이 될 것입니다. 또한 현재 사용되지 않은 데이터 테이블이나 열을 확인합니다. 마이그레이션 할 필요는 없습니다. 기능, 작업, SP 등과 동일하게 수행하십시오. 이제 쓰레기를 청소할 때입니다.

데이터베이스의 SPS 또는 동적 쿼리를 통해 데이터에 어떻게 액세스하고 있습니까? 새로운 DEV 데이터베이스를 Aganst로 실행하여 각 쿼리를 확인하고 여전히 작동하는지 확인하십시오. 다시 한 번 SQL의 두 맛이 어떻게 작동하는지 사이에는 차이가 있습니다. SQL을 사용하지 않았으므로 일반적인 실패 지점 중 일부가 무엇인지 잘 모르겠습니다. 당신이 그것에있는 동안 당신은 새로운 쿼리를 시간에 시간을 내고 그들이 최적화 될 수 있는지 확인하고 싶을 것입니다. 최적화는 데이터베이스마다 다르며, 이에있는 동안 마이그레이션의 일부로 수정할 수있는 쿼리가 제대로 수행되지 않을 수 있습니다.

사용자 정의 기능도 살펴 봐야합니다. 당신이 이것을하고 있다면 이것들을 잊지 마십시오.

예정된 작업을 잊지 마십시오. MySLQ에서도 확인하고 재현해야합니다.

정기적 인 일정에 따라 데이터를 가져오고 있습니까? 모든 수입품을 다시 작성해야합니다.

모든 것에 대한 열쇠는 테스트 데이터베이스를 사용하고 테스트, 테스트, 테스트를하는 것입니다. 특히 분기 별 또는 연간 보고서 또는 잊을 수있는 모든 것을 테스트하십시오.

당신이하고 싶은 또 다른 일은 버전이 제어되는 스크립트를 통해 모든 것을 수행하는 것입니다. 실패없이 DEV에서 순서대로 모든 스크립트를 실행할 수있을 때까지 프로덕션으로 이동하지 마십시오.

Answer 2

내가 잊어 버린 한 가지, 마이그레이션을 실행중인 DEV 데이터베이스 (SQL Server 데이터베이스)가 각 테스트 실행 직전 생산에서 업데이트되어 있는지 확인하십시오. 구식 기록에 대해 테스트하고 있었기 때문에 Prod에 무언가가 실패하는 것을 싫어합니다.

Answer 3

클라이언트 코드는 수정하기에 가장 복잡한 부분이 될 것입니다. 응용 프로그램에 매우 고품질 테스트 스위트가 없으면 많은 테스트를 수행해야합니다. 당신은 당신이 기대할 수있는 것, 심지어 같은 일에 의존 할 수 없습니다.

예, 데이터베이스 자체의 사항은 변경해야하지만 클라이언트 코드는 주요 조치가있는 곳이므로 많은 작업과 엄격한 테스트가 필요합니다.

데이터를 마이그레이션하는 것을 잊어 버리십시오. 그것은 당신의 마음에 마지막으로 있어야합니다. 데이터베이스 스키마는 너무 많은 어려움없이 변환 될 수 있습니다. 다른 데이터베이스 개체 (SPS,보기 등)는 문제를 일으킬 수 있지만 클라이언트 코드는 문제의 초점이있는 위치입니다.

데이터베이스 쿼리를 실행하는 거의 모든 루틴은 변경되어야하지만 절대적으로 모든 테스트를해야합니다. 이것은 사소하지 않을 것입니다.

현재 응용 프로그램의 주요 데이터베이스를 MySQL 4.1에서 5에서 5에서 마이그레이션하려고합니다. 이는 차이가 훨씬 적지 만 여전히 매우 큰 작업이 될 것입니다.