2011-05-01 3 views
5

게임에서 메시징 시스템의 백 엔드로 데이터베이스를 사용하려고합니다 (일종의 인스턴트 메시징). 로컬 데이터베이스를 사용하여받은 메시지와 데이터베이스를 내 서버에 저장합니다.데이터베이스 게임 메시징 스키마

사용자 : 여기 내가 사용하고있는 테이블은
이름 (VARCHAR)
나 displayName (VARCHAR)
currentGames (VARCHAR)

메시지 :
보낸 사람 (VARCHAR)
수신기 (VARCHAR)
메시지 (VARCHAR)
타임 스탬프 (int)를

내 놀이터 n은 사용자가 메시지를 보낼 때 먼저 로컬 데이터베이스에 메시지를 저장 한 다음 메시지를 서버로 보냅니다.

사용자가 새 메시지 (폴링)가 있는지 확인하면 사용자는 먼저 자신의 로컬 데이터베이스에서 최신 타임 스탬프를 가져 와서이 시간 이후에 보낸 모든 메시지에 대해 온라인 데이터베이스를 쿼리합니다. 수신 된 모든 메시지는 데이터베이스에서 삭제됩니다.

내가이 일을하는 방식에 문제가 있습니까? 나는 최악의 상황을 대비하려고 노력하고 있으며 이런 종류의 계획이 어떻게 확장 될지 전혀 모른다. 나는 "사용자"테이블에 대해 고유 ID를 사용하지 않고 있어야한다고 생각합니다. 데이터베이스 경험이 제한되어 있으므로 고유 한 자동 증가 ID의 중요성이나 여기에서 내가 어떻게 도움이되는지 완전히 이해하지 못합니다. 모든 조언/비평은 인정 될 것입니다.

+0

로컬 데이터베이스에서 일부 메시지를 먼저 저장하고 온라인 서버로 보내고 로컬 데이터베이스 메시지를 삭제합니다. 그래서 이걸 위해서'xml'과 같은 간단한 데이터 접근법을 사용할 수 있습니다. – Sudantha

+0

오, 아니요, 로컬 데이터베이스에 저장하여 사용자가 로그 오프 한 경우에도 여전히 메시지를 볼 수 있습니다. 로컬 db에 안전하게 저장되면 서버에서 삭제합니다. xml을 사용하여 데이터를 전송하고 있습니다. 질문은 내가 스키마를 올바르게 수행하고 있는지에 대한 것입니다. – jnortey

답변

2

다음 로컬 디자인과 같이 원하는 대부분의 게이머 태그는 일시적이며, 당신은 아마 (개인) 게이머의 ID 및 사용자 이름 (적어도 친구, 공공)를 구별 할 가입일 :

FRIEND -- The local user's own tag should go in here too. 
(user_id 
, current_gamer_tag 
, last_update_timestamp 
) 

GAME 
(game_id 
, game_name -- No timestamp here because the name doesn't change? 
) 

MESSAGE 
(message_id -- If you make this a GUID you can use it for synching with the server. 
, sending_user_id -- FK to FRIEND 
, receiving_user_id -- Also FK to FRIEND 
, timestamp 
, content 
) 

이것은 보내는 메시지와 수신 메시지를 모두 로컬에서 보관할 수 있으며 게이머 태그에 메시지 표시를 집중시키는 동시에 서버와 쉽게 동기화 할 수 있습니다. 그런데 세 가지 이상의 게임 플레이가있는 경우 receiving_user_id를받는 사람 목록이 포함 된 하위 테이블로 변경하는 것도 고려해 볼 수 있습니다.

고유 ID를 사용하는 것은 여러 가지 이유로 중요합니다. 가장 중요한 점은 게이머 태그를 수정하고 플레이어의 사용자 ID를 메시지 디스플레이에 표시하지 않아도된다는 것입니다.또한 bigint조차도 게이머 태그보다 작기 때문에 여기에 공간을 절약 할 수 있습니다. 이것은 확장 성을 위해 더 좋습니다. 메시지 ID에 증가하는 정수 대신 GUID를 사용하면 서버의 메시지 테이블에 "삽입 핫 스폿"이 없으므로 서버 메시지 테이블에 충분한 여유 공간이있는 한 더 잘 수행됩니다 . 또한 메시지 ID는 클라이언트 측에서 생성 될 수 있으며 메시지가 서버에 도달 할 때 키 충돌이 발생하지 않을 것이라고 확신 할 수 있습니다.

2

여기 내 모습입니다. 이것은 내가 어떻게 할 것인지 ...

모두 시스템 작동 방식에 달려 있습니다. 모든 사용자 이름을 한 번 사용하도록 허용하고 사용자가 변경할 수 없도록 한 경우 논리적으로 ID를 사용할 필요가 없습니다. 개인적으로는 사용자 데이터베이스에 auto_incremented id를 사용합니다. 내가 너라면 ID를 쓸거야. 모든 일이 단순해질거야. 로컬 데이터베이스에

Probally이 같은 뭔가가 필요합니다 : 그래서

Friend's database: 
USER_ID USERNAME 

Game's database: 
GAME_ID USER_PLAYING_ID 

Messages database: 
TO_USER TIMESTAMP GAME_ID 

를 온라인 데이터베이스에 제출할 때 당신이 보낼뿐만 아니라 게임 정보에 대한 사용자의 ID를해야합니다.

다시 말씀 드리지만 다시 말씀 드리겠습니다. 다른 모든 것 이외에, 당신이하는 일을 당신이 아는 것처럼 보입니다.

관련 문제