그런데 다시 게임을 유지 보수하다 보니, 플레이어 ID 대신 플레이어의 email 주소를 저장해야 하는 상황으로 바뀌었습니다. 그뿐만 아니라 지금까지는 아이템 종류만 로그로 남겼는데, 이제 아이템 이름까지 문자열 형태로 남겨야 하는 상황이 되었습니다. 이렇게 되면 점점 로그 테이블 구조는 복잡해지고 괴상해집니다.

기존 테이블의 필드 구조를 바꾸는 것은 여러분에게도 복잡한 일이지만, 데이터베이스 입장에서도 많은 양의 처리를 단시간에 해야 하는 어려운 일입니다. 예를 들어 기존 테이블에 레코드 1억 개가 이미 들어 있다고 가정합시다. 필드 하나를 추가하면 데이터베이스 엔진은 기존에 있는 레코드 1억 개 전체에 필드를 추가해야 합니다. 그 필드가 null을 갖고 있더라도 말이죠. 이때 데이터베이스 엔진은 장시간 작동을 멈춥니다. 하지만 게임 서비스가 작동을 멈추면 안 되는 상황이라면 이것은 문제가 되겠죠.

앞서 플레이어 정보를 데이터베이스에 저장할 때 외래 키를 사용했던 것을 기억하나요? 플레이어 정보를 구성하는 데이터 트리를 여러 종류의 테이블에 나누어서 저장할 수 있게 했습니다. 하지만 프로그램 구조가 복잡해질수록 테이블 구조도 변경해야 합니다. 유지 보수하면서 점점 힘들어지겠죠.

▲ 그림 8-1 사용자, 플레이어 캐릭터, 아이템의 테이블 관계