Личные сообщения - давайте расставим точки.

• Если цель похожего на классический чат один на один, вы можете реализовать дополнительную логику в приложении для создания диалога, когда два пользователя впервые начинают общаться.
• Для оптимизации работы можно добавить индексы на поля conversation_id, sender_id, created_at.
• Дополнительная таблица «сообщений прочитанных» может быть реализована для отслеживания статуса прочтения для конкретного пользователя в конкретном чате (например, если требуется хранить отметку для каждого участника в группе).

Ниже приведён SQL-пример создания таблиц (пример на PostgreSQL):

-- Таблица пользователей

CREATE TABLE users ( id SERIAL PRIMARY KEY, username VARCHAR(50) NOT NULL UNIQUE, email VARCHAR(255) NOT NULL UNIQUE, password_hash VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

-- Таблица диалогов (бесед)

CREATE TABLE conversations ( id SERIAL PRIMARY KEY, name VARCHAR(100), is_group BOOLEAN DEFAULT FALSE, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP );

-- Таблица участников беседы (связующая таблица)

CREATE TABLE conversation_participants ( conversation_id INTEGER NOT NULL REFERENCES conversations(id) ON DELETE CASCADE, user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE, joined_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (conversation_id, user_id) );

-- Таблица сообщений

CREATE TABLE messages ( id SERIAL PRIMARY KEY, conversation_id INTEGER NOT NULL REFERENCES conversations(id) ON DELETE CASCADE, sender_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE, message_text TEXT NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, status VARCHAR(20) DEFAULT 'sent' );

-- Индексы для ускорения выборок (опционально)

CREATE INDEX idx_messages_conversation ON messages(conversation_id); CREATE INDEX idx_messages_sender ON messages(sender_id);

-- Дополнительно можно создать таблицу для статуса чтения сообщений отдельным пользователям

CREATE TABLE message_read_status ( message_id INTEGER NOT NULL REFERENCES messages(id) ON DELETE CASCADE, user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE, read_at TIMESTAMP, PRIMARY KEY (message_id, user_id) );

Эта схема позволяет:

• Отслеживать всех пользователей сайта.
• Создавать диалоги/беседы, как для двух пользователей, так и для групповых чатов.
• Хранить сообщения, отправленные в рамках каждого диалога.
• Отслеживать участников бесед, их вступление в чат, а также при необходимости статус прочтения каждого сообщения для каждого пользователя.

Как это понять для групповых чатов ?

Нужно только 2 собеседника в 1 чате.

К примеру user1 написал user2, user 2 ответил user 1. - далее удаление у себя сообщение удалили к примеру 2 пользователя то оно удаляется автоматом из БД у обоих пользователей.

Видите не все так просто

К примеру user1 написал user2, user 2 ответил user 1. - далее удаление у себя сообщение удалили к примеру 2 пользователя то оно удаляется автоматом из БД у обоих пользователей.

Видите не все так просто

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

Как это понять для групповых чатов ?

Нужно только 2 собеседника в 1 чате.

У меня в этом практики ноль, но, могу разобраться в прочем что и делаю.

Мне нужна некая простая база (рабочая) чтобы наглядно было, потом уже проще будет.