数据库的游戏消息模式
我试图使用一个数据库作为后端为我的比赛的消息系统（有点像即时通讯）。我正在使用本地数据库在我的服务器上存储收到的消息和数据库以发送它们。下面是我使用的表：数据库的游戏消息模式
用户：
用户名（VARCHAR）
显示名（VARCHAR）
currentGames（VARCHAR）
消息：
发件人（VARCHAR）
接收机（ VARCHAR）
消息（VARCHAR）
时间戳（int）的
我的PLA n是当用户发送消息时，我首先将消息存储在本地数据库中，然后将消息发送到服务器。
当用户检查，看看是否有任何新的消息（轮询），他首先从他的本地数据库获取最新的时间戳和利用这段时间来查询该时间之后发送的所有邮件的在线数据库。所有收到的信息都会从数据库中删除。
是不是有什么毛病我这样做的方式是什么？我正在努力为最坏的情况做好准备，我不知道这种计划将如何扩展。我没有为“用户”表使用唯一的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比一个玩家标签小。这对于可伸缩性更好。对于消息ID使用GUID而不是递增的整数意味着您不会在服务器的消息表中拥有“插入热点”，只要您的服务器消息表中包含足够的可用空间，它就会更好地运行。此外，消息ID可以在客户端生成，并且您可以非常确信消息到达服务器时不会发生任何重大冲突。
这是我的样子。这是我会怎么做....
这一切都取决于你的系统是如何工作的。如果允许每个用户名使用一次而不允许用户改变它，那么逻辑上你不需要使用一个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在本地数据库中，你需要有这样的事情。
同样，我只是会怎么做。除了其他一切，似乎你知道你在做什么。
因此，在本地数据库中，您首先存储一些消息并发送到在线服务器，并根据我的理解删除本地数据库消息？ ...因此，对于这种情况我可以使用简单的数据处理方式，比如'xml' – Sudantha 2011-05-01 04:36:04
哦不，我将它们存储在本地数据库中，以便即使用户注销时仍可以查看消息。一旦他们安全地在本地数据库中，我将它们从服务器中删除。我使用XML来传输数据。问题更多的是关于我是否正确地执行模式。 – jnortey 2011-05-01 04:55:47