数据库游戏消息模式

Question

我正在尝试使用数据库作为游戏中消息系统的后端(有点像即时消息).我正在使用本地数据库来存储收到的消息和我的服务器上的数据库以发送它们.以下是我使用的表格:

用户:
userName(varchar)
displayName(varchar)
currentGames(varchar)

消息:
sender(varchar)
receiver(varchar)
message(varchar)
timestamp(int)

我的计划是,当用户发送消息时,我首先将消息存储在其本地数据库中,然后将消息发送到服务器.

当用户检查是否有新消息(轮询)时,他首先从其本地数据库获取最新时间戳,并使用此时间在在线数据库中查询在此之后发送的所有消息.然后从数据库中删除收到的所有消息.

我这样做的方式有问题吗？我正在努力为最坏的情况做准备,我不知道这种计划将如何扩展.我没有在"用户"表中使用唯一的ID,我觉得我应该这样做.由于我的数据库经验有限,我不完全理解独特的自动增量ID的重要性或它如何帮助我.任何建议/批评将不胜感激.

Answer 1

由于大多数玩家标签都是暂时性的，并且您可能希望区分玩家的 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）都比玩家标签小。这更有利于可扩展性。使用 GUID 而不是递增的整数作为消息 ID 意味着您的服务器消息表上不会有“插入热点”，只要您的服务器消息表内置有足够的可用空间，该热点就会表现得更好。此外，消息 ID 可以在客户端生成，您可以非常确信当消息到达服务器时不会发生任何按键冲突。