데이터베이스 설계

데이터베이스는 데이터가 모여있는 것이다.

그 데이터를 보다 효율적으로 관리하기 위해 나온게 관리 시스템이고, 덕분에 데이터베이스라고 하면 데이터베이스 관리 시스템(Database Management System)으로 MSSQL이나 MySQL을 떠오르게 됬다.

데이터들의 효율적인 관리를 하려다 보니 데이터들의 상관 관계를 고려해서, 중복된 데이터를 없애고 무결성이 깨지는 일이 없도록 제약조건을 걸게 되었다. 그러다가 아직까지 주도권을 잡고 있는 관계형 데이터베이스가 나왔고.

덕분에 데이터베이스에 뭔가를 저장하기 위해서는 데이터베이스 테이블을 설계해야하고, 각 column들 간의 관계와 제약조건을 잘 설정해서, 중복된 데이터를 없애고 무결성을 지키는게 당연하게 여기게 되었다.

그런데 사실 데이터베이스 시스템의 목적이 단순히 데이터의 persistence만을 위한 것이라면 데이터를 어떻게 저장하든 크게 상관 없는거잖아?

게임 서버를 만든다고 할 때, 사용자의 정보를 데이터베이스로 관리한다고 해보자. 그러면 사용자의 정보의 각 항목에 해당되는 column을 갖는 table을 만들어서 잘 넣어주고 관리할 수도 있고, 아니면 게임 서버에서 쓰는 구조체 binary를 그냥 blob으로 넣어버릴 수도 있겠다.

당연히 양자간의 장단점이 존재하고(심지어 후자의 방법도 장점이 존재한다: parsing 비용이 안 든다!) 뭐가 더 좋냐, 라고 하면 당연히 그 상황에서 더 적합한 방법이 더 좋은 방법이라고 할 수 밖에 없다.

하지만 통상적으로 게임 내 사용자 정보 같은 경우는 column의 개수가 추가되고 변경될 일이 있으니까 binary로 넣어버리면 column이 하나 추가될 때마다 기존 사용자들의 데이터를 migration하느라 꽤 시간을 소모하게 될 것이다.