Одна таблица MySQL для личных сообщений

Question

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

CREATE TABLE IF NOT EXISTS `pm` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL,
  `to` int(11) NOT NULL,
  `date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `subject` varchar(255) DEFAULT NULL,
  `message` text NOT NULL,
  `read` tinyint(1) NOT NULL DEFAULT '0',
  `deleted` tinyint(1) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
  FOREIGN KEY (user_id) REFERENCES User(user_id)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;

У меня есть 2 столбца, которые определяют статус сообщения: read и deleted

Если read = 1, сообщение было прочитано получателем.Если deleted = 1, отправитель или получатель удалили сообщение из отправленного или полученного почтового ящика.Если deleted = 2 оба пользователя удалили сообщение, то удалите строку из таблицы базы данных.

Answer 1

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

Рекомендации по производительности таблиц MySQL:

1. Добавить соответствующие индексы в таблицы. Индексы предназначены не только для первичных / уникальных ключей, добавляйте их в часто используемые столбцы.
2. Явно укажите максимальную длину. Таблицы фиксированной длины работают быстрее, чем их аналоги
3. Всегда иметь столбец идентификатора.
4. Добавьте NOT NULL, где только можете. Нули все еще занимают место
5. Знайте свои типы данных. Знание - сила и может сэкономить на производительности и пространстве

Интересные статьи:
Тест VarChar / TEXT
Аналогичный вопрос
Некоторые рекомендации
Требования к типу данных для хранения

Статьи и некоторые из перечисленных мною пунктов могут быть не на 100% правильными или надежными, поэтому обязательно сделайте небольшую часть собственных исследований, если вы заинтересованы в дальнейшей настройке своей производительности.

Answer 2

Несколько комментариев:

Charset=latin1 собирается разозлить некоторых людей, которых я бы предложил charset=utf8.

Я бы предложил поставить проверку внешнего ключа не только наuser_id, но также и на to.

Также я бы поставил индекс на date, так как вы будете выполнять большую сортировку в этом поле.

Вам нужно разделить удаленное на два поля, иначе вы не будете знать, какой пользователь удалил сообщение.(deleted_by_user, deleted_by_recipient)

Обратите внимание, что date является зарезервированным словом, и вам необходимо изменить его на message_date или `backtick` в своих запросах.

Answer 3

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

Answer 4

Возможно, вы также захотите применить ключевые отношения с ON DELETE и ON UPDATE:

FOREIGN KEY (user_id) REFERENCES User(user_id) ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (to) REFERENCES User(user_id) ON DELETE CASCADE ON UPDATE CASCADE

Удаление или изменение пользователя будет распространять изменения или удаления в таблицу сообщений.

Answer 5

Для отображения как входящих сообщений, так и исходящих сообщений отправителей (и, соответственно, возможности удалять сообщения), вам, вероятно, понадобится больше информации, чем то, что вы в данный момент закодировали. Я бы предложил «удаленное» поле для каждой партии. (Пока это ограничено только 1 пользователем на каждом конце и никакими широковещательными сообщениями, это работает. Это не масштабируется для широковещательных сообщений, однако, для эффективной работы потребуется более 1 таблицы)

Answer 6

некоторые комментарии:

неплохо.

Я бы назвал таблицу тем, что другие люди могут догадаться вне контекста. так что, возможно, личное сообщение вместо вечера.

Я бы явно указывал имена столбцов пользователей, поэтому, возможно, from_user_id и to_user_id вместо 'user_id' и 'to'

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