Как мне хранить тривиальные данные в базе данных?
У меня есть веб-приложение, которое позволяет людям загружать анимацию флипбука. Всегда есть много запросов на новые функции, такие как:
Пометка пользователей (как пометка человека в посте на Facebook)
Пометка их заметок (например: пометка видео на YouTube категориями или пометка вопросов Stack Exchange: database-design)
Связывание их флипнотов с несколькими релевантными каналами для лучшего шанса найти зрителей
Для таких вещей, как подписка / подписка, у меня есть таблица follows,
+---------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+-------------+------+-----+---------+----------------+
| followID | int(11) | NO | PRI | NULL | auto_increment |
| followingUser | varchar(16) | NO | | NULL | |
| followedUser | varchar(16) | NO | | NULL | |
+---------------+-------------+------+-----+---------+----------------+
Однако я довольно не решаюсь создавать десятки таблиц для работы с метаданными. Там слишком много всего. Я также не решаюсь использовать типы данных TEXT для хранения, скажем, массивов тегов. Я слышал плохие вещи об эффективности; и я имею дело с сотнями тысяч строк в одной части сайта и почти четырьмя миллионами в одной таблице в другой. Небольшие неэффективности не всегда остаются маленькими, если учесть масштабируемость. принимать order by rand() В качестве примера.
Итак, какие подходы я могу рассмотреть для хранения и организации тривиальной информации в моей базе данных? Я мог бы значительно улучшить пользовательский опыт, если бы я мог отслеживать больше информации.
Я использую PHP и MySQL.
Решение
Самый простой и эффективный способ сделать тегирование — это создать основной список тегов, а затем использовать отношение «многие ко многим», чтобы записать, какие теги применяются к каждому из ваших FLIPBOOKS, Рассмотрим это ERD:
FLIPNOTE_TAG Таблица просто простое пересечение, которое содержит внешние ключи к вашему FLIPNOTE стол и твой TAG основной список. Как вы получаете теги, зависит от ваших бизнес-правил. В Stack Exchange теги представляют собой модерируемый список элементов. На YouTube это просто тупые строки, которые пользователи могут добавлять по желанию.
В любом случае, наличие основного списка тегов значительно упрощает поиск отдельных тегов для отслеживания или просмотра.
Кроме того, в отличие от частичного поиска совпадения текста в массивах строк, который является чрезвычайно медленным при любом разумном масштабе, поиск индекса внешнего ключа таблицы пересечений для одного или нескольких ключей тегов является очень быстрым и масштабируемым.
Другие решения
Я думаю, что следующая база данных довольно хорошо структурирована, чтобы быть честной, но вам нужен только followUser или followUser (я бы выбрал последнее и назвал его userBeingFollowed для большей ясности), как будто Person A следует за Person B, тогда это автоматически верно, что Person За B следует Лицо A, и поэтому вам не нужны оба. Кроме того, вам нужен столбец отметки времени, чтобы записать время, когда произошло следующее, и вы должны хранить его как long (или BigInt (11)).
Оператор SQL — это простой запрос INSERT, который очень легко понять.
detector