Схема обмена сообщениями в базе данных

Question

Я пытаюсь использовать базу данных в качестве бэк-энда для системы обмена сообщениями в моей игре (что-то вроде мгновенного обмена сообщениями). Я использую локальную базу данных для хранения полученных сообщений и базу данных на моем сервере для их отправки. Вот таблицы, которые я использую:

Пользователи:
userName (varchar)
displayName (varchar)
currentGames (varchar)

Сообщения:
Отправитель (VARCHAR)
приемник (varchar)
сообщение (varchar)
метка времени (int)

Мой план состоит в том, что когда пользователь отправляет сообщение, я сначала сохраняю сообщение в его локальной базе данных, а затем отправляю сообщение на сервер.

Когда пользователь проверяет наличие новых сообщений (опрос), он сначала получает последнюю метку времени из своей локальной базы данных и использует это время для запроса в онлайн-базе данных всех сообщений, отправленных после этого времени. Все полученные сообщения затем удаляются из базы данных.

Что-то не так с тем, как я это делаю? Я пытаюсь подготовиться к худшему, и я понятия не имею, как будет масштабироваться этот план. Я не использую уникальный идентификатор для таблицы «Пользователи» и считаю, что должен. Поскольку мой опыт работы с базами данных ограничен, я не до конца понимаю значение уникального идентификатора автоинкремента или того, как он мне здесь поможет. Любой совет / критика будет принята.

Answer 1

Поскольку большинство тегов геймеров являются временными, и вы, вероятно, захотите провести различие между идентификатором игрока (личным) и его именем пользователя (общедоступным, по крайней мере, для друзей), вам нужен локальный дизайн, подобный этому:1003 * Он хранит как исходящие, так и входящие сообщения локально и позволяет отображать сообщения с акцентом на теги игрока, в то же время их легко синхронизировать с сервером.Кстати, вы можете также рассмотреть возможность изменения receive_user_id на вложенную таблицу, содержащую список получателей, если у вас есть три или более игровых процесса.

Использование уникальных идентификаторов важно по многим причинам.Наиболее важным является то, что он позволяет вам изменять теги геймеров и не дает вам возможности раскрывать идентификаторы пользователей ваших игроков на экранах сообщений.Здесь также есть экономия места, потому что целое число, даже bigint, меньше тега игрока.Это лучше для масштабируемости.Использование GUID вместо увеличивающегося целого числа для идентификатора сообщения означает, что у вас не будет «горячей точки» вставки в таблицу сообщений вашего сервера, которая будет работать лучше, если в таблице сообщений вашего сервера имеется достаточно свободного места.,Кроме того, идентификаторы сообщений могут быть сгенерированы на стороне клиента, и вы можете быть достаточно уверены, что при попадании сообщений на сервер не будет никаких столкновений клавиш.

Answer 2

Вот мой взгляд на это. Вот как бы я это сделал ....

Все зависит от того, как работает ваша система. Если разрешить использование каждого имени пользователя один раз и не позволить пользователю изменить его, то логически вам не нужно будет использовать идентификатор. Лично я использую идентификатор auto_incremented для своей базы данных пользователей. Если бы я был тобой, я бы использовал удостоверение личности, это бы все упростило.

Возможно, в локальной базе данных вам понадобится что-то вроде этого:

Friend's database:
USER_ID  USERNAME

Game's database:
GAME_ID   USER_PLAYING_ID

Messages database:
TO_USER  TIMESTAMP  GAME_ID

Таким образом, при отправке в онлайн-базу данных у вас будет идентификатор пользователя для отправки, а также информация об игре.

Опять же, как бы я это сделал. Кроме всего прочего, похоже, что вы знаете, что делаете.