При разработке схемы для БД (например, MySQL) возникает вопрос, следует ли полностью нормализовать таблицы.

С одной стороны, объединения (и ограничения внешнего ключа и т. Д.) Очень медленные, а с другой стороны, вы получаете избыточные данные и потенциальную несогласованность.

Является ли «оптимизация в прошлом» правильным подходом здесь? то есть создайте обычную БД, а затем посмотрите, что можно денормализовать для достижения оптимального прироста скорости.

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

Должен ли тот факт, что эта БД будет с большой нагрузкой, повлиять на решение?