2011-05-01 87 views
5

我試圖使用一個數據庫作爲後端爲我的比賽的消息系統(有點像即時通訊)。我正在使用本地數據庫在我的服務器上存儲收到的消息和數據庫以發送它們。下面是我使用的表:數據庫的遊戲消息模式

用戶:
用戶名(VARCHAR)
顯示名(VARCHAR)
currentGames(VARCHAR)

消息:
發件人(VARCHAR)
接收機( VARCHAR)
消息(VARCHAR)
時間戳(int)的

我的PLA n是當用戶發送消息時,我首先將消息存儲在本地數據庫中,然後將消息發送到服務器。

當用戶檢查,看看是否有任何新的消息(輪詢),他首先從他的本地數據庫獲取最新的時間戳和利用這段時間來查詢該時間之後發送的所有郵件的在線數據庫。所有收到的信息都會從數據庫中刪除。

是不是有什麼毛病我這樣做的方式是什麼?我正在努力爲最壞的情況做好準備,我不知道這種計劃將如何擴展。我沒有爲「用戶」表使用唯一的ID,我覺得我應該這樣做。由於我的數據庫經驗有限,我不完全瞭解獨特的自動遞增ID的意義或者它對我的幫助。任何意見/批評將不勝感激。

+0

因此,在本地數據庫中,您首先存儲一些消息併發送到在線服務器,並根據我的理解刪除本地數據庫消息? ...因此,對於這種情況我可以使用簡單的數據處理方式,比如'xml' – Sudantha 2011-05-01 04:36:04

+0

哦不,我將它們存儲在本地數據庫中,以便即使用戶註銷時仍可以查看消息。一旦他們安全地在本地數據庫中,我將它們從服務器中刪除。我使用XML來傳輸數據。問題更多的是關於我是否正確地執行模式。 – jnortey 2011-05-01 04:55:47

回答

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,它會簡化一切。提交給在線數據庫時

Friend's database: 
USER_ID USERNAME 

Game's database: 
GAME_ID USER_PLAYING_ID 

Messages database: 
TO_USER TIMESTAMP GAME_ID 

那麼你將有用戶的ID發送給以及遊戲信息:

Probally在本地數據庫中,你需要有這樣的事情。

同樣,我只是會怎麼做。除了其他一切,似乎你知道你在做什麼。