mysql - 数据库游戏消息传递模式

Question

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

用户:
用户名 (varchar)
显示名称(可变字符)
当前游戏(varchar)

消息:
发件人(varchar)
接收器(varchar)
消息(可变字符)
时间戳(整数)

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

当用户检查是否有任何新消息(轮询)时，他首先从他的本地数据库获取最新的时间戳，并使用这个时间来查询在线数据库以获取该时间之后发送的所有消息。然后从数据库中删除所有收到的消息。

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

Answer 1

由于大多数玩家标签都是 transient 的，您可能想要区分玩家的 ID(私有(private))和他们的用户名(公开，至少对 friend 来说)，那么您需要这样的本地设计:

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 可以在客户端生成，您可以非常确信当消息到达服务器时不会发生任何键冲突。