MySQL — CURRENT_TIMESTAMP + MILLISECONDS как первичный ключ для чата?
Есть задача написать чат (что-то типа службы поддержки для пользователей). Решил сделать 2 таблицы для хранения, 1-я `chat` - поля:
`id` (UNSIGNED BIGINT 20 PRIMARY KEY ))
`created_at` - DATETIME DEFAULT CURRENT_TIMESTAMP
`opened_by` - ID пользователя кто открыл чат
`accepted_by` - ID пользователя (support) тот кто принял чат в работу
2-я таблица с сообщениями `chat_messages` - поля:
chat_id - FOREIGN KEY `chat.id` (ID чата, внешний ключ на chat.id)
created_at - DATETIME DEFAULT CURRENT_TIMESTAMP дата создания сообщения
sender - UNSIGNED TNINYINT 1 - (либо 0 либо 1, где 0 это сообщение от chat.opened_by, 1 - от chat.accepted_by)
recipient_id - ID пользователя получателя
message - текстовое сообщение
status - TNINYINT 1 (статус чата, что то типа открыт/закрыт, потом кроном закрытые чаты буду переносить в архив и удалять их соответственно из таблиц chat, chat_messages)
Уникальный ключ `chat_id`, `created_at`, `sender_id`, `recipient_id`
Проблема в том, что в одну секунду можно отправить только одно сообщение, то есть, например если пользователь отправит 2 сообщения в одно и то же время (например в 13-01-2022 12:15:33), то будет ошибка уникальности ключа, можно ли как-то хранить еще миллисекунды для уникальности ключа? То есть, чтобы первичный ключ выглядел примерно так - `chat_id`, `created_at`, `sender_id`, `recipient_id`, `milliseconds`.
Первичный ключ в виде UNSIGNED BIGINT 20 делать не хочу тк не знаю как быстро заполнится таблица сообщений.
Схема, мягко говоря, кривенькая... явно составитель ни на какой анализ даже не заморачивался, просто посмотрел в потолок, что-то там увидел, и решил "А сделаю-ка я вот так!"... Всё стереть и начать с нуля, заново. Но по науке. Анализ. Диаграмма. И только потом - структуры.
А с нынешним БСК лучше даже не пытаться работать - это не структура, а поле с граблями.
