SQL обобщение / специализация, избыточность данных

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

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

• Это не сломалось, пока он не сломался.
• Вы не можете улучшить то, что вы не измеряли.
• Программы тратят удивительное количество времени в самых прочных местах.
• Запустите его. Заставьте его работать правильно. Заставьте его работать быстро.
  • Оптимизация
  • - это буквально последнее, что вы должны делать.
  • делать что-то не так быстро, не приносит большой пользы.

Также несколько комментариев по денормализации:

• Вы не можете денормализовать то, что не нормировано.
• Большинство разработчиков не знали бы третьей нормальной формы, если бы выскочили из-за своего экрана, закричали, как банши, и взломали бейсбольную биту над головами.
• Денормализация предлагается как панацея для проблем с производительностью базы данных. Проблема в том, что слишком часто те, кто рекомендует денормализацию, никогда ничего не нормализуют.
• "Денормализация по соображениям производительности" - повод для небрежного, "делайте то, что всегда делалось", думая, особенно когда такая денормализация закреплена в дизайне.

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

Поделитесь и наслаждайтесь.