我正在尝试使用数据库作为游戏中消息系统的后端(有点像即时消息).我正在使用本地数据库来存储收到的消息和我的服务器上的数据库以发送它们.以下是我使用的表格：
用户：
userName(varchar)
displayName(varchar)
currentGames(varchar)
消息：
发件人(varchar)
接收器(varchar)
消息(varchar)
时间戳(int)
我的计划是,当用户发送消息时,我首先将消息存储在其本地数据库中,然后将消息发送到服务器.
当用户检查是否有新消息(轮询)时,他首先从其本地数据库获取最新时间戳,并使用此时间在在线数据库中查询在此之后发送的所有消息.然后从数据库中删除收到的所有消息.
我这样做的方式有问题吗？我正在努力为最坏的情况做准备,我不知道这种计划将如何扩展.我没有在“用户”表中使用唯一的ID,我觉得我应该这样做.由于我的数据库经验有限,我不完全理解独特的自动增量ID的重要性或它如何帮助我.任何建议/批评将不胜感激.
最佳答案
由于大多数玩家的标签是短暂的,你可能想成为游戏玩家的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,并且您可以非常确信当消息到达服务器时不会发生任何密钥冲突.