문제

임의의 SQL2003 호환 RDBMS에서 동일한 데이터베이스를 생성하고 채우기 위해 SQL2003 코드 조각을 생성하는 mysqldump 또는 유사한 도구의 주문이 있습니까?

(지금 시도하고 있는 것은 MonetDB 입니다)

도움이 되었습니까?

해결책

DDL 문은 본질적으로 데이터베이스 공급업체마다 다릅니다.기본 구조는 동일하지만 각 공급업체는 유형, 인덱스, 제약 조건 등을 정의하는 방법에 대해 각자의 견해를 가지고 있습니다.

반면에 DML 문은 이식성이 뛰어납니다.그러므로 나는 다음을 제안한다:

  • 데이터 없이 데이터베이스를 덤프(mysqldump --no-data)하여 스키마를 가져옵니다.
  • 다른 DB에 스키마를 로드하기 위해 필요한 변경을 수행합니다. 이러한 작업은 직접 수행해야 합니다(그러나 일부 검색/바꾸기는 가능할 수 있음).
  • 확장 삽입을 해제하고 테이블 생성 없이 데이터를 덤프합니다(--extended-insert=0 --no-create-info).
  • 다른 DB에 대해 결과 스크립트를 실행합니다.

원하는 대로 작동해야 합니다.

그러나 애플리케이션을 다른 데이터베이스 공급업체로 이식하는 경우 다른 많은 사항이 필요합니다.스키마와 데이터를 이동하는 것은 쉬운 일입니다.도입된 버그, 다양한 동작 및 성능 테스트를 확인하는 것은 어려운 일입니다.

최소한 애플리케이션의 모든 단일 쿼리를 테스트하여 새 데이터베이스의 유효성을 확인하세요.이상적으로는 더 많은 일을 하세요.

다른 팁

이건 좀 힘든 것 같아요.바닐라 유형(varchar, 정수 등)을 사용하는 매우 간단한 DB 구조가 없다면 아마도 마이그레이션 도구를 작성하여 최상의 결과를 얻을 수 있을 것입니다.Perl과 같은 언어(DBI를 통해)에서는 이는 매우 간단합니다.이 프로그램은 기본적으로 한 데이터베이스에서 읽고 다른 데이터베이스에 삽입하는 에코 루프입니다.Google이 알고 있는 이러한 종류의 코드의 예가 있습니다.

데이터 이동의 명백한 문제 외에도 일부 데이터 유형이 표현되는 방식에 대한 더 미묘한 문제가 있습니다.예를 들어, MS SQL의 날짜/시간 필드는 MySQL의 형식과 다릅니다.BLOB와 같은 다른 데이터 유형은 한 RDBM에서 다른 RDBM과 다른 용량을 가질 수 있습니다.이식하기 전에 대상 DB 시스템의 데이터 유형 정의를 잘 이해하고 있는지 확인해야 합니다.

물론 마지막 문제는 애플리케이션 수준 SQL 문이 새 시스템에 대해 작동하도록 하는 것입니다.내 작업에서는 그게 가장 어려운 부분이다.날짜 계산은 특히 DB에 국한된 것으로 보이며, 인용 규칙과 같은 성가신 것들은 지속적인 짜증의 원인입니다.

프로젝트에 행운이 있기를 바랍니다.

SQL Server 2000 또는 2005에서는 개체에 대한 스크립트를 생성하도록 할 수 있지만 다른 RDBMS로 얼마나 잘 전송될지는 잘 모르겠습니다.

스크립트 생성 옵션은 아마도 가장 쉬운 방법일 것입니다.하지만 몇 가지 데이터 유형에 대해서는 의심할 여지 없이 일부 검색/바꾸기를 수행해야 합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top