MYSQL схема для системы комментариев - PullRequest
Новая
       138

MYSQL схема для системы комментариев

2 голосов
/ 04 мая 2020

У меня есть базовая c система комментариев для приложения, которое я создаю со следующей настройкой таблицы 

CREATE TABLE `meet_comment` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `meet_id` int(11) NOT NULL,
 `user_id` int(11) NOT NULL,
 `date_created` datetime NOT NULL,
 `comment` mediumtext NOT NULL,
 PRIMARY KEY (`id`),
 KEY `meet_id` (`meet_id`),
 KEY `user_id` (`user_id`),
 CONSTRAINT `meet_comment_ibfk_1` FOREIGN KEY (`meet_id`) REFERENCES `meet` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
 CONSTRAINT `meet_comment_ibfk_2` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

meet_id - это ссылка на объект, который комментирует пользователь. Это прекрасно работает, хотя на данный момент, если пользователь редактирует комментарий, я просто обновляю поле «Комментарий».

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

CREATE TABLE `meet_comment` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `meet_id` int(11) NOT NULL,
 `user_id` int(11) NOT NULL,
 PRIMARY KEY (`id`),
 KEY `meet_id` (`meet_id`),
 KEY `user_id` (`user_id`),
 CONSTRAINT `meet_comment_ibfk_1` FOREIGN KEY (`meet_id`) REFERENCES `meet` (`id`) ON DELETE CASCADE ON UPDATE CASCADE,
 CONSTRAINT `meet_comment_ibfk_2` FOREIGN KEY (`user_id`) REFERENCES `user` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

CREATE TABLE `meet_comment_content` (
 `revision` int(3) NOT NULL,
 `meet_comment_id` int(11) NOT NULL,
 `date_created` datetime NOT NULL,
 `comment` mediumtext NOT NULL,
  UNIQUE KEY `revision_2` (`revision`,`meet_comment_id`),
 KEY `revision` (`revision`),
 KEY `meet_comment_id` (`meet_comment_id`),
 CONSTRAINT `meet_comment_content` FOREIGN KEY (`meet_comment_id`) REFERENCES `meet_comment` (`id`) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=13 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

Если это так, что будет лучшим способом для запроса таблиц, я думаю, я могу сделать объединение, чтобы получить необходимые данные?

Спасибо за любая помощь или указатели.

Ура

1 Ответ

0 голосов
/ 08 мая 2020

История изменений приводит к перетягиванию каната -

  • Простота или нет
  • Эффективность в масштабе или нет
  • Сложность запросов или не
  • дисковое пространство или раздувание

Рассмотрим следующий «общий» принцип:

Имеют две таблицы:

  • Current - текущая версия комментария
  • History - все версии комментария

Current делают запросы main проще и более эффективный.

Создание или редактирование комментария означает INSERT или UPDATE в Current, плюс (всегда) INSERT в History.

History иметь немного схему, отличную от Current, так как должен быть номер редакции и, возможно, другие даты / flags / et c.

Это не относится к дисковому пространству; Я подозреваю, что вы можете продержаться некоторое время, прежде чем беспокоиться о таком. Один из методов - «сжать» основной столбец TEXT и поместить его в BLOB. (Примечание: еще одна разница в схеме. И сложность в коде.) Типичный текст сжимается на 3: 1.

Примечание: int(3) - (3) ничего не говорит. INT всегда 4 байта. Рекомендуется использовать SMALLINT UNSIGNED, который занимает 2 байта и имеет диапазон 0,64K.

Я бы отказался от FOREIGN KEYs, особенно CASCADE; вероятно, в этих двух таблицах будут запутываться ссылки. В любом случае вам нужно будет тщательно написать код для выполнения различных задач, что устранит необходимость в FK.

Каждая таблица должна иметь PRIMARY KEY. Для «кластеризации» данных я рекомендую (comment_id, revision), а не наоборот.

И, подумайте, является ли meet_id частью PK.

...