Таблицы и их связи для месенджера на сервере

Всем привет.
Пишу для себя в качестве тренировки клиент и сервер месенджера на Qt.
И та и другая часть работают, сервер регистрирует юзера, юзер заходит, все норм.
Но теперь нужны таблицы для сохранения сообщений(группового чата и чата между 2 людьми)
Таблицы:
User(id, name, pass, email)
Chat(id, name)
Message(user_id, chat_id, timestamp, message)

Таблица Chat по моему мнению хранит имена чатов для всех общений как для двух так и для групповых.
Вопрос в именовании. Например User1 и User5. 1 решил написать 5 юзеру, когда он выбрал его и написал мы создали имя их чата и внесли в таблицу(Как формировать имена для их чата и как определять их чат если потом 5 юзер выбрал 1 и пишет ему?).

Таблица Message тут по сути все сообщения для всех видов чатов.
Правильно ли в однйо таблицу хранить все эти данные для всех юзеров, или для каждого юзера своя таблица всех его общений? Если да то как лучше формировать связи?

И еще вопрос, на данном этапе я использую SQlite, стоит ли продолжать на нем в данном проекте работать или лучше перейти на MySQL или на PostgreSQL?
Заранее благодарю отозвавшихся за правки и советы.

0

Я сейчас разбираюсь с этим запросом что вы очень хорошо описали. Могли бы только описать в каком порядке происходит раскрутка запроса? Если я правильно понимаю то два SELECT которые в INNER JOIN и LEFT JOIN выполняются первыми?

Добавлено через 10 минут
Попробовал я ваш запрос, и это действительно то что я (пытался) хотел получить. первые 17 записей в моем случаи то что нужно, а потом много раз дублируется, пока не понимаю почему.

0

Занят был, извините.

Сообщение от SektorCT Я сейчас разбираюсь с этим запросом что вы очень хорошо описали.

Описал хорошо, а работает неправильно

Сообщение от SektorCT Могли бы только описать в каком порядке происходит раскрутка запроса? Если я правильно понимаю то два SELECT которые в INNER JOIN и LEFT JOIN выполняются первыми?

Нет, в данном случае они выполняются по порядку, в котором написаны. В другом порядке запросы выполняются, например, если написано:

Сообщение от SektorCT Попробовал я ваш запрос, и это действительно то что я (пытался) хотел получить. первые 17 записей в моем случаи то что нужно, а потом много раз дублируется, пока не понимаю почему.

Потому что я неправильно написал запрос
Вот теперь проверил, переписал.
И для удобства я:
1) изменил имена в таблицах,
2) создал псевдонимы для двух таблиц,
3) создал представление, связывающее таблицы.
Сначала покажу код, который у меня получился, а потом объясню, что это значит, и зачем.
Код создания таблиц:
Код создания псевдонимов таблиц:
Код создания связывающего представления:
Код внесения данных:
Выполняем первый запрос:
Результат:
Выполняем второй запрос:
Результат:
Теперь объяснение, почему я так делаю.

1) Видите, какие короткие два запроса получились в конце? Это благодаря тому, что я связываю таблицы не в каждом запросе, а связываю их один раз в представлении. То есть, я один раз подумал над связями, один раз правильно написал эти связи, и забыл о них. Всё, теперь в запросах мне не нужно думать над этими связями, а просто писать:
Это очень удобно.

2) Зачем полям таблиц такие имена типа "User_ID", "User_Name"? Что, разве нельзя просто "ID", "Name"? Можно. Но если в двух таблицах есть поля с одинаковым названием (например, в таблице user есть поле id и в таблице chat есть поле id), то когда мы их джойним простым способом user JOIN chat, и делаем из этого SELECT:
, то СУБД выдаёт ошибку, смысл которой можно описать так: "Чувак, здесь два поля с названием "id", и я не знаю, какое из них тебе нужно, сорян". А если мы называем все поля таким способом "User_ID", "Chat_ID", то получается, что названия разные, и можно смело джойнить две разные таблицы простым способом "User" JOIN "Chat", и при селекте у СУБД не возникает проблем:
И здесь такой ошибки не будет. Поэтому я всегда называю поля таким вот способом: "<имя сущности>_<имя свойства>" (через знак подчёркивания). И обязательно в кавычках, иначе большие буквы будут превращаться в маленькие внутри СУБД (PostgreSQL), из-за чего могут быть ошибки.

3) Что такое псевдоним таблицы? Это по сути та же самая таблица, но выступающая в запросах под другим именем. Хотя, технически в СУБД это не таблица, а представление, но по сути для меня это таблица под псевдонимом. В каких случаях таблице нужен псевдоним? В случае, например, когда пользователь может выступать в разной роли. Вот как в Вашем случае, где пользователь может выступать: 1) в роли владельца аккаунта, КОТОРЫЙ СМОТРИТ на свой экран, 2) в роли не-владельца, а участника системы, НА КОТОРОГО СМОТРЯТ. Когда такое происходит, то возникает потребность джойнить таблицу "User" саму с собой "User" JOIN "User", а так делать нельзя — СУБД выдаст ошибку. И чтобы СУБД не выдавала ошибку, нужно дать таблице псевдоним, например "Owner", чтобы получилось: "Owner" JOIN "User". И тогда такой ошибки не будет. Но ведь этого можно достичь и без создания представления? Да, можно. Зачем тогда создавать представление? Чтобы создать ещё и псевдонимы полей этой таблицы. Ведь если поля мы оставим без изменений, то получится, что и в таблице "Owner" есть поле "User_ID", и в таблице "User" тоже есть поле "User_ID", при этом мы их джойним, и возникает ошибка, рассмотренная в пункте 2 выше. И вот чтобы такой ошибки не возникало, я создаю псевдоним для каждой таблицы, которую нужно будет джойнить простым способом саму с собой.

Если нужно объяснить что-то ещё, то пожалуйста, можете спрашивать. Только иногда я могу не сразу ответить.

И посмотрите, пожалуйста, на результаты выполнения запросов. Это то, что нужно, или не совсем?

1

Сообщение от Annemesski просматривает хранящиеся у него сообщения и отправляет пользователю те, которых нет в списке отправленном пользователем. Для хеширования сообщений посмотрите в сторону QUuid class.

Сообщение от Annemesski Для хеширования сообщений посмотрите в сторону QUuid class.

У меня вот к этому 2 вопроса только.
1: на стороне клиентов в каком виде должны хранится сообщения, в виде такой же базы с одной таблицей Сообщения аналогичной серверной? Или в каком то другой виде?
2: могли бы описать примерно как это хеширование через QUuid должно работать? Первый раз с этим сталкиваюсь.

Спасибо

0

Сообщение от SektorCT на стороне клиентов в каком виде должны хранится сообщения

Решительно не важно в каком виде, тут главное чтобы клиенту и серверу был доступен одинаковый набор данных о сообщении чтобы его идентифицировать.

Сообщение от SektorCT описать примерно как это хеширование через QUuid должно работать?

А почитать? Коротко суть в том, что UUID - это по сути это просто очень большое число, которое можно генерировать по некоторому набору данных, при этом одни и теже исходные данные дают один и тот же UUID, а малейшие различия дают сильные различия в UUID.

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

Несмотря на это UUID - это очень удобный инструмент для синхронизации данных в распределенных системах, позволяющий обмениваться не полными данными, а этаким их описанием и в случае отсутствия описателя докачивать недостающие куски данных. А учитывая приведенные выше недостатки такого подхода нужно всего лишь гарантировать что со стороны сервера и клиента всегда будет использоваться один и тот же алгоритм генерации - это можно гарантировать тем, что генерация UUID будет происходить только на сервере, а сервер будет пересылать сообщения вместе с их UUID.

Ваш алгоритм может выглядеть примерно так:
1. Сервер получает сообщение от пользователя и перед тем как принять решение о передаче его другим пользователям сохраняет сообщение у себя генерируя для него UUID, например, по тексту самого сообщения, временной метке получения и пары отправитель получатель, после чего пытается переслать это сообщение всем причастным.
2. Клиент, каждый раз подключаясь к серверу, запрашивает у него список UUID всех сообщений которые есть в БД сервера, затем сравнивает полученный с сервера список UUID со своим вычитая свой список из списка сервера и, если разница не пуста, значит на сервере есть сообщения которых нет у пользователя.
3. Пользователь докачивает к себе те сообщения которых у него нет.

0

Сообщение от Annemesski например, по тексту самого сообщения, временной метке получения и пары отправитель получатель, после чего пытается переслать это сообщение всем причастным

Спасибо, я теперь понял что uuid это именно хеш из совокупности этих данных.
И еще один вопрос, вот если у меня со стороны сервера в базе для всех юзеров и всех чатов только 1 таблица messages то из практической точки зрения стоит ли со стороны юзера под каждого создавать базу и у каждого юзера в ней будут таблицы под каждую чат комнату? Я просто подумал вдруг это было бы удобнее.
Или стоит иметь одну базы для любого юзера но таблицы уже буду под каждого юзера но со всеми его сообщениями?
Интересно просто вопрос со стороын продуктивности работы с хешированием и доступами.
Спасибо.

0

Сообщение от Annemesski Ваш алгоритм может выглядеть примерно так:

Вы не могли бы подсказать как правильно бы выгледела проверка и обновление базы?
Предположим у юзера пара чатов. Он подключился к серверу, сервер собрал для данного юзера все сообщения по всем доступным ему чатам. И посылает юзеру примерного вида QMap<int, QList<QUuid>> то есть номер чата и хеш каждого сообщения попорядку.
Предположим:
ChatRoom1
- message1
- message2
- message3
ChatRoom2
- message1

а вот у клиента в базе по чату 1 только 2 сообщения.
ChatRoom1
- message1
- message3

Получается мы каждый хеш что прилетел от сервера должны сравнить со всеми сообщениями у клиента? Я правильно понимаю?
Вопрос, как определять по uuid какое именно сообщение отсутствует и как его дописывать?
И если я правильно понимаю то клиент обнаружив отсутствие сообщения должен уже посылать запрос серверу и сервер найти нужное и уже послать обратно?
Спасибо.

0

Сообщение от SektorCT QMap<int, QList<QUuid>>

Плохая идея. Стройте uuid на основе полной информации о сообщении: в каком оно чате, от какого пользователя кому адресовано, когда пришло на сервер и само сообщение, все эти атрибуты хранятся на сервере, при пересылке сообщения клиенту, также пересылайте и атрибуты, а на стороне пользователя программа пусть раскладывает сообщения по категориям согласно атрибутам.

0

Сообщение от Annemesski Плохая идея.

Не совсем вас понял в чем плохая идея.
Я на стороен сервера при подключении клиента и по его запросу формирую контейнер с номером чата и всеми сообщениями данного чата, QMap<int, QList<QUuid>> и в таком виде посылаю клиенту. uuid как раз и формирую из всех перечисленных вами параметров.
Я просто не могу придумать как сравнивать лучше и определять по uuid а потом еще и сообщить серверу какого сообщения нету у клиента.

0