색인순차접근방식(ISAM)에서 관계형 데이터베이스(DB)로 전환하는 것은 쉬운 일이 아니다. 많은 기업들은 기존 애플리케이션에 가능한한 최소의 변화만 가해 사용하려 한다. 여기에는 예측가능한 몇가지 문제점들이 있다.성능보통 관계형 DB는 ISAM DB보다 성능면에서 좋은 편이지만, 항상 그런 것은 아니다. 프로그램은 전혀 바뀌지 않은 채 ISAM에서와 똑같은 방법으로 관계형 DB에 접근한다면 ISAM을 사용할 때와 동일한 성능은 절대 얻을 수 없다. ISAM을 염두에 두고 개발된 프로그램이 사용하는 싱글 레코드, 싱글 테이블 방식에 관계형 DB가 최적화 돼있지 않기 때문이다.ISAM DB 백엔드에서 관계형 DB 백엔드로 직접 전환하게 되면 성능이 떨어질 수 있다. 다만 신중한 인덱스 사용, DB 서버 메모리 증설, 또는 튜닝 등을 통해 이같은 성능저하를 어느정도 관리하에 둘 수는 있다. 물론 전환 작업을 할 때는 성능 평가에 얼마만큼의 시간을 투자할 것인가도 결정해야 한다.대부분 애플리케이션은 하드웨어적인 지원을 통해 ISAM이 내던 성능 정도까지는 낼 수 있다. 즉 DB 서버에 RAM만 추가해도 ISAM에서 관계형으로 직접 전환할때 발생하는 자연스러운 성능저하 문제는 충분히 극복할 수 있다. 프로그램 변경DB 마이그레이션에 따른 필요성으로 인한 프로그램상의 변화를 단순히 ‘프로그램 변경’이라고 한다면, ‘변경’이라는 말을 제대로 이해하지 못하는 것이다. 중요한 것은 프로그램 자체에 변경을 가하는 것 이상으로, 사용자의 사고방식도 바꿔야 한다는 점이다. 관계형 DB로 전환한다는 것은 소프트웨어를 설계의 기본적인 프로세스에도 상당한 변화가 발생함을 의미한다.레코드가 아니라 레코드 세트다ISAM의 방식, 즉 ‘각 레코드를 순차적으로 처리한다’는 생각을 관계형 방식, 즉 ‘처리해야 하는 레코드를 세트별로 요청한다’는 생각으로 바꾸는 것. 이것은 겉보기엔 작은 변화같지만 매번 테스트가 필요한 상당히 복잡한 변화다. 리턴된 레코드 목록을 특정 범주(criteria)로 필터링하는 작업은 첫번째 단계는 무척 단순하다. 이 첫번째 단계는 관계형 DB에서 성능을 끌어내기 위한 필수요소라고 할 수 있다. SQL로 설명하자면 결과를 어디서 끊을지 정해주는 ‘WHERE’ 절을 더하는 것과 같다.레코드 처리에 있어서 ‘세트’ 개념을 활용하는 두번째 단계는 첫번째보다 약간 어렵다. 어떻게 다수의 레코드 값을 하나의 레코드에 모을까, 다른 레코드를 업데이트하는데 이를 어떻게 활용할까 등의 문제는 레코드 목록을 필터링하는 것보다 훨씬 더 복잡한 작업이다.고객의 총 구매 기록을 업데이트 하는 작업을 예로 들면, 전통적인 ISAM DB 프로그래머라면 먼저 고객을 순차적으로 읽어들이고, 이들의 모든 트랜잭션을 읽고, 변경사항이 있으면 결과를 저장하는 순서로 작업을 진행할 것이다. 관계형 DB 프로그래머라면 이 같은 작업을 '절차 코드없이 요청할 수 있는 것'이라고 생각할 것이다. SQL 한 줄(Listing A. 정도의 문장이 되지 않을까)이면 같은 작업을 ISAM에서보다 훨씬 빠르게 처리할 수 있다.MS SQL 서버에서 사용되는 간단한 SQL 코드를 사용하면 모든 고객의 트랜잭션을 업데이트할 수 있다. 같은 일을 절차적 코드를 사용해서 수행하려고 하면 코드 길이도 무척 길어질 것이며, 실행에도 많은 시간이 소요될 것이다. 데이터를 세트 개념으로 생각하는 것은 단순히 관계형 DB에 필요한 코드를 작성하기로 결심하는 것 보다 더 심사숙고 해야하는 부분이다.순차적인 방식에서 이와같은 세트 방식으로 한순간에 패러다임을 바꿀 수는 없다. 개발자들은 매번 고개를 드는 과거 습관과 마주쳐야 할 것이다.로직 바꾸기관계형 DB로의 전환은 애플리케이션 로직도 상기한 세트 기반 사고방식을 적용해 바꿔야 한다는 것도 의미한다. 관계형 DB의 모든 장점과 혜택을 누리기 위해서는 현재 사용하고 있는 애플리케이션의 비즈니스 로직을 다른 방식으로 생각하고 바꿔야 한다. 비즈니스 로직이 단순하다면 관계형 DB로 전환하는 작업도 그만큼 수월할 것이다.하지만 비즈니스 로직이란 것은 과거의 이니셔티브들이 실타래처럼 서로 얽혀 있거나, 지난 수년동안 테스트조차 해보지 못한 코드들로 이뤄진 경우가 다반사다. 불행한 일이지만 이같은 상황에서 새로운 코드가 모든 상황에서 만족스러운 성능을 낼 것이라고는 장담할 수 없다. 소프트웨어가 지원하도록 된 조건들이 현재의 제품 데이터 내에는 포함돼있지 않았을 수도 있기 때문이다.애플리케이션 로직을 재구성할 의향이 있다면 상당한 수준의 성능 향상을 이룰 수 있겠지만 대부분의 기업에서는 이같은 일은 엄두도 낼 수 없는게 현실이다.인프라 변화 이해하기ISAM 기반 DB에서 관계형 DB로 전환하는데 필요한 마지막 요소는 인프라에 대한 시각의 변화다. 관계형 DB를 사용할 때는 무정지형(fault tolerant) 하드웨어나 클러스터링 등 ‘고가용성’ 솔루션을 고려하는 것이 중요하다. 이러한 기술 및 솔루션은 DB의 안정성을 증대시켜 ISAM에서 관계형으로의 전환을 더욱 가치있게 만들 수 있다.물론 ISAM에서 관계형 DB로 전환하는 데는 비용이 든다. 하지만 이같은 단기적인 비용은 장기적인 관점에서 안정성을 확보할 수 있다는 장점으로 상쇄할 수 있다. 장기적인 안정성은 결국 더 큰 비용 절감효과로 이어진다. @