플레이어 정보를 서버에 저장하는 방법은 크게 두 가지, '파일' 또는 '데이터베이스' 저장 방식이 있다.
상용으로 서비스되는 게임들은 대부분 플레이어 정보를 데이터베이스에 저장한다. 예를 들어 Microsoft SQL Server를 데이터베이스로 사용하는 경우 여러 플레이어의 정보는 덩치 큰 파일 몇 개에 모두 저장된다(데이터베이스를 통한 저장일지라도 내부적으론 파일시스템의 파일에 저장됨).
플레이어 각각의 데이터를 저장하거나 불러오는 속도는 데이터베이스보다는 파일이 빠르다. 데이터베이스도 결국 파일 시스템을 사용하기 때문이다. 그러나 나머지 부분은 데이터베이스가 모두 앞선다. 데이터를 관리하거나 분석하는 속도도 데이터베이스가 훨씬 빠르다.
source: http://contents2.kocw.or.kr/KOCW/data/document/2019/cup/ryuwooseok0714/3.pdf
1. 데이터 무결성 => 제약(constraints) 기능
잘못된 상태의 데이터가 들어가는 것을 제약 기능을 통해 막는다.
파일에 저장할 때는 잘못된 범위 값이 들어가는 것을 막을 방법이 없다. 전적으로 알아서 해결해야 한다. 하지만 DB에서는 잘못된 범위의 값이 들어가거나 잘못된 조건 값이 들어가는 것을 예방할 수 있다.
예를 들어 이름이 같은 플레이어 캐릭터가 2개 이상 존재하지 못하게 할 수 있다.
2. 원자성과 영속성 => DBMS 회복 및 백업 기능
플레이어 A와 B가 있을 때, A와 B 사이에 물물 교환을 하는 상황을 생각해보자. 원하는 것은 A와 B의 데이터 거래를 완료한 후 모두 변경되거나 중도 와해된 후 어느 쪽도 변경되지 않는 것이다.
어떠한 경우라도 A와 B 중 데이터 하나만 변경된 상태가 되어서는 안된다. DB는 이러한 요구사항도 해결해 준다.
단순 파일을 사용할 때는 데이터를 백업하거나 복원하는 프로그램을 직접 만들어야 함. DBMS에는 이러한 기능이 기본으로 많이 내장됨.
3. 일관성과 고립성 => DBMS 병행제어 기능
플레이어 A와 B가 있을 때, A와 B 사이에 물물 교환을 하는 상황을 생각해보자. 원하는 것은 A와 B의 데이터 거래를 완료한 후 모두 변경되거나 중도 와해된 후 어느 쪽도 변경되지 않는 것이다.
어떠한 경우라도 A와 B 중 데이터 하나만 변경된 상태가 되어서는 안된다. DB는 이러한 요구사항도 해결해 준다.
파일에 저장할 때는 둘 이상의 프로세스나 쓰레드가 동시에 액세스하는 상황을 직접 중재해야 하지만, DBMS는 이러한 상황을 알아서 해결해 줌. 특히 데이터 경쟁 상태(data race condition) 같은 현상이 생기지 않게 함.
4. 구조 변경의 용이성
데이터 구조가 바뀌는 경우 단순 텍스트 파일이면 컨버팅(converting) 과정을 거쳐야 한다. 하지만 DB는 즉시 변경이 가능할 때가 많다.
5. 다각적 데이터 검색 => 쿼리(Query)
DB에서는 다음과 같은 구체적인 상황에서도 빠르게, 다각적으로 데이터를 검색할 수 있어 편리하다.