Схема форума: должен ли "Темы" столить фонтан topic_starter_Id? Или это избыточная информация?

Question

Я создаю приложение для форума на php и у меня есть вопрос относительно дизайна базы данных:

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

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

• Получить все сообщения по теме и упорядочить по отметке времени.Но что будет, если кто-то сразу ответит на тему.Тогда у меня есть первые два сообщения с одинаковой отметкой времени (маловероятно, но возможно).Я не могу знать, кто был первым.Это также нормализуется, но становится дороже после увеличения таблицы.

• Получите все сообщения по теме и упорядочите по post_id.Это столбец auto_increment.Можно ли гарантировать, что база данных будет использовать идентификатор индекса в порядке вставки?Будет ли запись, вставленная позже, всегда иметь более высокий идентификатор, чем предыдущие строки?Что если я удалю сообщение?Будет ли моя база данных использовать post_id позже?Это MySQL, который я использую.

• Самый простой способ отклониться от курса - просто добавить поле в таблицу «Темы» с topic_starter_id и покончить с этим.Но это не нормализуется.Я полагаю, что это также самый эффективный метод после того, как таблицы тем и постов вырастают до миллионов строк.

Каково ваше мнение?

Answer 1

Комментарий Зеда довольно заметен.

Как правило, вы хотите добиться нормализации, но денормализация может сохранить потенциально дорогие запросы.

В моем опыте написания программного обеспечения для форумов (пять лет коммерчески, пять лет в качестве хобби), этот конкретный случай требует денормализации для сохранения одного запроса. Совершенно разумно и приемлемо хранить как отображаемое имя и идентификатор первого пользователя, так и отображаемое имя и идентификатор последнего пользователя, , при условии, что код, добавляющий сообщения в темы, всегда обновляет запись . Вам нужен один и только один путь кода здесь.

Answer 2

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

Чтобы быть более конкретным, есть оптимизация, которая будет работать без денормализации (и сопутствующих головной боли обслуживания / целостности данных), но ТОЛЬКО если база пользователей достаточно мала (скажем, <1000 пользователей, ради аргумента - зависит в наших масштабах. Наши приложения используют этот подход с 10k + отображений). </p>

А именно, у вас есть прикладной уровень (код, работающий на веб-сервере), извлекайте список пользователей в надлежащий кэш (например, с возможностью истечения срока действия данных). Затем, когда вам нужно напечатать имя первого / последнего пользователя, найдите его в кеше на стороне сервера.

Это позволяет избежать дополнительного запроса для каждого просмотра страницы (так как вам нужно только получить полный список пользователей ОДИН РАЗ за N просмотров страницы, когда истекает срок действия кэша или когда обновляются данные пользователя, что должно привести к истечению срока действия кэша).

Это добавляет крошечное время процессора и использование памяти на веб-сервере, но в «Ещё одной священной войне» (например, тратить больше ресурсов на стороне БД или на стороне сервера приложений) я твердо уверен в том, что «не тратьте ресурсы БД» «Лагерь, видя, как масштабировать БД гораздо сложнее, чем масштабировать веб-сервер или сервер приложений.

И да, если эта (или другая столь же хитрая) оптимизация неосуществима, я согласен с Чарльзом и Зедом в том, что у вас есть компромисс между нормализацией (меньше головной боли, связанной с целостностью данных) и увеличением производительности (на одну таблицу меньше). включите в некоторые запросы). Поскольку я являюсь агностиком в этой конкретной священной войне, я просто иду с тем, что дает лучшие предельные выгоды (например, сколько потери производительности в сравнении с тем, сколько затрат / риска от ненормализации)