DB의 사용은 어떻게 하는지 알고 싶습니다.
별도의 DB서버를 병렬로 둔다고 들었거든요.
그럼..

디비는 데이터 베이스로 데이터만 관리해주는 서버 입니다.
보통 RDB를 많이 쓰는데 RDB는 관계형 디비라고 하고
태이블 구조입니다.
Object 구조의 OODB도 있지만 아직 표준이 없어서
많이 쓰이지 않고 있습니다. 오라클 8은 ORDB라고 객체디비(OODB)와
관계형디비(RDB)의 중간적인 구조를 가지고 있고요.
디비를 쓰면 데이터의 관리가 편해지고 프로그램을 짜기가 간편해
지지요. 데이터의 백업등도 디비에서 알아서 해주니까요.
하지만 그에 따른 부하와 안전성 속도 문제등을 충분히 고려하셔야 합니다.
디비는 필수는 아니고 선택입니다.
공개된 디비도 몇개 있긴 한데. 별로 안정적이지 않아
추천해드리고 싶진 않군요. mini SQL이나 포스타그래스 등도 있고.
오라클이나 인포믹스 싸이베이스등의 상용 디비도 리눅스에서 돌릴 수 있습니다.
하지만 디비를 쓴다면 아래에 쓰셧듯이 따로 디비 서버를 돌리는게 좋습니다.
그래야 부하를 줄이고 속도문제도 해결 할 수 있으니까요. 정두재 (isoft )

게임 제작시 DB 에 관한 질문

ODBC로 쓰고 있습니다. 시험용이라 일단은 간단하게 access를 쓰지만,
조만간 mssql등을 찾아볼 짬입니다.
테스트판이지만,잘 돌아가더군요. 하지만,access는 그리 좋다고 보이지는
않습니다. 효율적이지 못한 것 같더군요. mfc로 만들었기 때문에,데이터
소스나 테이블이 일부 변경되는 선에서는 손쉽게 고칠 수 있다고 보이기
때문에 mfc에서 odbc를 쓸 뿐입니다. 참,winnt에서 겜서버를 돌리고 있습니다.
솔루션을 찾는다면,우선적으로 따져야 할 것이 몇가지 있을겁니다. 플랫폼,
시스템 사양,프로그램 구성,게임의 스타일,참여 인원,접속선 등등이겠죠.
잘 모르시겠다면 위에 언급한 따질 것들을 나열해서 올리세요.
막걸리

안녕하세요. 온라인 액션게임을 만들고 있는 사람입니다.

아래 튕기는 문제는 많이 해결됬습니다.
좀더 두고 보고 괜찮은거 같으면 제가 쓴 방식을 게시판에 올릴께요.
이번에는 사용자 DB에 관한 질문인데요.
SQL같은 프로그램을 사용하면 CPU점유나 Memory사용이 많지 않나요?
그냥 사용자 DB를 만들때, 적당한 디렉토리 만든후 사용자 ID를
파일이름으로 쓰면 어떨까요?
아디디 검사할때 파일 오픈에 실패하면 사용자 등록이 안된거고,

파일내에 패스워드및 기타 정보는 포함하고 있고...
이렇게 하면 사용자 관리도 쉬울거 같고, DB 억세스 안하고 console모드로
서버를 작성해도 되고, 기타 다른 OS로 포팅하기도 편할것 같은데.
단, NT나 LINUX, UNIX에서 한 디렉토리에 만들 수 있는 파일수가 얼마나
되는지 궁금하네요. 1만명 이상이 가입하면 파일수가 1만개가 넘어가니
문제가 될것도 같고.
답변 부탁드립니다.
너무 개념적인 부분에만 치우치긴 했어도 프로그램세게 3월호 내용
괜찮네요.

필수가 아니라 선택입니다.
디비 자체가 파일 시스템을 대체하는 부분도 있고.
파일 시스템 보단 체계적으로 관리가 된다는 점이
장점이라고 할 수 있겠군요.
NT5.0에선 파일 시스템 자체가 디비형태가 된다고 합니다.
OS에 디비를 포함시키는 거죠.
디렉토리 갯수 문제는 걱정하지 마십시요.
몇 십만개를 만들어도 문제가 되지 않습니다. (제가 만들어 봤씁니다.)
물론 Searching이나 List가 느려지는건 어쩔 수 없는 거지만요.
RDB자체의 테이블 구조의 한계 때문에 표현 못하는 데이터 형도 있습니다.
그럼에도 불구 하고 디비를 쓰는건 디비에서 제공하는 것들이 많기
때문이죠. 특히 안정성과 강력한 기능(Search, Join , 클러스트링 ,
Stored Procedure등의 여러가지 편리한 기능)을 제공 하기 때문 입니다.
백업도 편해지고, 간단한 쿼리문만 알면 검색이 쉬워지지요.
하지만 디비 자체가 게임을 위해 나온것이 아니기 때문에

많은 유저와 막대한 쿼리에 대해 어떻게 반응할지는 테스트 해봐야 합니다.
내부적인 구현만 메모리나 파일 베이스로 하고 백업만 디비를 쓰더라도
꽤 쓸만 하니까요.
뭐 디비를 쓸려면 쓰되 잘 써야 한다라는 글이 되어 버렸군요. ^^;

DB를 쓰면 당연히 시스템의 부하를 많이 먹게 됩니다. 형곤님이 생각하신 방법도
괜챦은 방법이라고 생각합니다. 사용자 계정이름의 앞글자 아스키코드별로
디렉토리를 세분화하여 각각의 파일로 저장하면 되겠지요. 파일이 존재하지 않으면
계정이 없는 것이니깐... DB검색이 필요가 없으니 간단하죠.
이런 방법은 많이들 쓰는 것으로 압니다

제가 실제 게임서비스에서 디비를 사용하고 있습니다.
모 좋다, 나쁘다의 개념에서 벗어나서 몇가지 말씀드리고
싶군요.. 첫번째 게임을 만들었을때.. 화일로 작성하는 방법을
썼었죠.. (Gunchase라는 단순한 게임이었습니다. -.-;;)
물론 빠르고 괜찮은 점이 많았습니다. 이방법도 나쁘지 않다고
생각하고 있고요.. 두번째 게임.. 이제 베타테스트를 하고 있는데요.
어쩌다가보니.. MS의 SQL Server를 쓰게 되었습니다. DBLIB를 이용해서

다이렉트로 디비에 억세스를 하고요.. 성능면에서는 그다지 부하나
메모리 점유는 없습니다. 주로 다루는 데이타는 사용자의 일반 정보(
이름, 주소, 이메일같은것들).. 그리고 게임상에 필요한 데이타들(
머리아이템의 무게, 가격, 레이다 탐지거리.. 총아이템의 공격력
사정거리..등등)를 저장하고 쓰는데요.. 한사람이 로그인할때
SELECT문의 시작하는 쿼리가 15개정도 갑니다. 그렇지만 느리다거나
메모리가 모잘란다는 경우는 없었습니다. 다만. 어플리케이션에서
한가지 컨셉을 잘못 잡은것이 있어서 주기적인 옵티마이즈가 필요하

긴 하지만요.. 하지만 이건 데이타베이스를 써서 그런건 아니지요.
음.. 그리고.. 일단 데이타베이스에 써놓으니까.. 웹과의 연동이
쉽게 되더군요.. 모.. 사용자의 총점순위별 TOP10페이지나 게시판에
인증에 관련된 부분들이.. 화일로 썼다면 무지 노가다(?) 했을 부분
이었죠.. (헐.. 쓰다보니 디비가 좋다는듯 들리는군요...-.-;;)
모.. 누군가가 전산학의 역사는 데이타베이스의 역사다..라는 말을
들은것 같기도한데.. 맞는 말인거 같습니다.

^__^;
아.. 또 한가지 빼먹었네요... 분산서버구축에도 많은 도움이 되겠군요.
중앙 디비에서 관리를 하면 서버를 분산시키더래도 사용자인증이나 데이타
는 일괄되게 관리가 되겠죠..
하지만.. 한편으론 많은 손이 가는건 사실입니다. 트랜잭션로그나 디비백업.
등등의 메인티넌스에 손이 좀 많이 가요.. ^__^;
그럼.. 전준수 (Jun92 )