불행히도 온라인 게임 시스템에서 데이터베이스 시스템은 고객과 가장 멀리에 존재한다. 더욱 불행한 것은 데이터에 가장 가까이에 존재하는 것이다. 데이터에 가장 가까이에 있다는 그것 하나만으로 데이터에 대한 책임은 모두 데이터베이스 시스템이 가지게 된다. 책임이라는 것은 '무결성'이라는 용어로 표현되고 있다. 데이터베이스라는 국가에서 살고 있는 DBA는 무결성에 대한 아래의 4대 의무를 반드시 지켜야 한다.

• 개체무결성을 지킬 것
  
• 참조무결성을 지킬 것
  
• 속성무결성을 지킬 것
  
• 기타 업무규칙을 지킬 것
  
  

개체무결성은 각각의 개체를 식별할 수 있어야 함을 의미한다. 물리적으로 구현을 경우 Primary Key(PK)로 불리게 된다. 즉, 하나의 ROW가 삽입된다면 개체무결성 규칙을 지키기 위해 똑같은 Row가 있는지 확인과정을 거쳐야 함을 뜻한다. 강한 참조무결성은 개체가 참조하는 개체의 존재여부를 반드시 확인해야 함을 뜻한다. 속성무결성은 도메인 제약조건 또는 Assertion('주장'이라고 많은 서적들에서 번역되고 있지만 마음에 와닿지는 않는다)을 말한다. 예를 들어 '주민등록번호'는 가중치 코드로써 복잡한 로직을 가진다. 또한 숫자만이 사용될 수 있으며, '1~6자리는 생년월일'과 같이 내부적인 의미도 있다. 기타 업무규칙은 위에서 설명한 3가지 무결성이외의 조직에 필요한 기타규칙을 말한다. 물리적으로 저장 프로시저 또는 트리거등으로 구현된다.

여기에서 DBA의 불행은 시작된다. 왜냐하면 무결성은 그 자체가 부하이기 때문이다. 특히 온라인 게임DB의 경우는 성능이 매우 중요한 고려사항이기 때문에 더욱 불행해진다. 게임의 특성에 따라서 틀리지만 일반적인 MMORPG게임의 경우 하루 5천 만 건 이상의 트랜잭션이 발생하는게 다반사다. 하드웨어는 정해진 용량이 있고, 고객의 수는 늘어남에 따라 고객들이 게임을 원할하게 할 수 있는 것이 최종목표가 되므로 무결성을 보장을
위한 자그마한 부하도 부담이 되는 상황이 발생하게 된다. 그렇다고 의사결정권자는 하드웨어의 증설을 허락하지도 않는다. 여기서 DBA는 둘 중 하나의 선탞을 하게 된다.

1. Data Layer 외의 Layer로 무결성을 보장하게 한다.
   
2. 그냥 무결성을 보장하지 않는다.
   
   

1번을 선택하면 DBA는 개발자를 설득해야 한다. DBA는 몸이 매우 피곤해진다. DB를 사용하는 어플리케이션들의 복잡도는 증가할 것이며, 유지보수의 비용도 함께 증가할 것이다. 그러나 어디에선가는 무결성이 보장되므로 DBA의 의무는 공익근무요원(공익근무요원을 비하하는 것은 절대 아니다.) 수준으로 느슨해 질 것이다. 2번을 선택한다면 DBA는 양심에 털이 나기 시작하면서 DBA라는 명함을 들고 고개를 뻣뻣이 들고 다니지 못하
는 정신적인 고통에 시달리게 된다. 왜 고통에 시달리까? 무결성이라는 돌을 멀리 던져버렸지만 이 돌은 언젠가 부메랑이 되어 뒤통수를 칠 것을 알고 있기 때문이다. (이것을 알지 못한다면 아직 DBA라는 타이틀을 과감하게 포기하라!)