Представьте, что у нас есть веб-сайт, на котором пользователи могут читать статьи, просматривать фотографии, смотреть видео и многое другое. Каждый «элемент» может быть прокомментирован, так что нам нужно место для сохранения этих комментариев где-то Давайте обсудим возможности хранения для этого случая.
Распределенное решение
Очевидно, что мы можем создавать отдельные таблицы для каждого «элемента», поэтому у нас есть такие таблицы:
CREATE TABLE IF NOT EXISTS `article_comments` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`createdBy` int(11) DEFAULT NULL,
`createdAt` int(11) DEFAULT NULL,
`article` int(11) DEFAULT NULL,
`content` text,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
, а затем, очевидно, photo_comments, video_comments и так далее. Преимущества этого способа заключаются в следующем:
- мы можем указать внешний ключ для каждой таблицы "item",
- база данных разбита на логические части.
- нет проблем с экспортом таких данных.
Недостатки:
- много таблиц
- вероятно, трудно поддерживать (добавление полей и т. Д.)
Централизованное решение
С другой стороны, мы можем объединить все эти таблицы в две:
CREATE TABLE IF NOT EXISTS `comment_types` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
и
CREATE TABLE IF NOT EXISTS `comments` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`createdBy` int(11) DEFAULT NULL,
`createdAt` int(11) DEFAULT NULL,
`type` int(11) DEFAULT NULL,
`content` text,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
Таблица comment_types - это словарь, он содержит пары ключ-значение прокомментированного элемента «тип» и его имя, например:
1:Articles
2:Photos
3:Videos
В таблице comments хранятся обычные данные с дополнительным полем type.
Преимущества:
- Обслуживание (добавление / удаление полей),
- Добавление новых типов комментариев "на лету".
Недостатки:
- Труднее мигрировать / экспортировать,
- Возможное падение производительности при запросе большого набора данных.
Обсуждение:
- Какой вариант хранения будет лучше с точки зрения производительности запросов (предположим, что набор данных достаточно большой для этого),
- Опять производительность - добавит ли INDEX на
type удаление или радикально уменьшит это падение производительности?
- Какой вариант хранения будет лучше с точки зрения управления и возможной миграции в будущем (распределенное будет лучше, конечно, но давайте посмотрим, далеко ли не централизованный)