nomarketing

Всем привет!

Есть ли в Linux утилита чтобы проверить список из тысяч URL на ответ 200, 404 и т.д. Чтобы можно было из файла со списком большого количества ссылок проверить их какой код ответа у них?

В linux полно утилит по умолчанию, их просто комбнировать надо)

Вывести в консоль

или в файл

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

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

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

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

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

• Если цель похожего на классический чат один на один, вы можете реализовать дополнительную логику в приложении для создания диалога, когда два пользователя впервые начинают общаться.
• Для оптимизации работы можно добавить индексы на поля 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) );

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

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

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

Чаты по своей сути ближе к темам форума, чем к почте и почтовым ящикам.