Я могу ожидать увеличение производительности от удаления этого СОЕДИНЕНИЯ?

Правильный ответ - измерить его в целевой среде , чтобы увидеть, имеет ли это значение. Затем проведите анализ затрат и выгод, чтобы понять, стоит ли оно того.

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

Схемы базы данных - это , а не операции «установить и забыть», они должны периодически настраиваться по мере изменения базовых данных. Это то, за что платят администраторам баз данных - постоянный мониторинг и настройку.

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

Я не могу комментировать, соответствует ли MySQL моему определению достойной СУБД - я сам являюсь специалистом по DB2. Но возврат из третьей нормальной формы - это испытанный и проверенный метод выжать все до последней капли производительности из баз данных и, если вы понимаете последствия, вполне приемлем. Очень немногие люди жалуются на то, что их базы данных занимают слишком много места на диске. Многие жалуются на то, как медленно выполняются их запросы.

Просто имейте в виду, что реверсия - это то, что вы делаете , если и когда у вас есть проблемы с производительностью. Это не то, что следует делать только потому, что вы думаете, что это может снизить нагрузку.Если нагрузка (или затраченное время) на самом деле не является проблемой, часть выгоды вашего анализа затрат / выгод равна нулю, поэтому любой разумный счетчик bean скажет вам, что это означает «без изменений».

Основываясь на ваших добавленных вопросах, у меня есть пара замечаний:

• Во-первых, столбец нагота . Скажите, пожалуйста, как мне получить доступ к этой базе данных: -)
• Вы должны только извлечь нужные столбцы. Если имя пользователя - это все, что вам нужно из таблицы User , вы не должны получать все эти лишние данные в первом запросе. Возможно, то же самое и с предметом Item - получите только то, что вам нужно.
• Убедитесь, что у вас есть индексы для всех столбцов, используемых в предложениях WHERE - это также может повлечь за собой комбинированные индексы (с несколькими столбцами). То, что будет индексироваться, зависит от ваших запросов, но каждый столбец, используемый в предложениях WHERE , является хорошим началом для анализа.
• Для больших таблиц вы можете рассмотреть возможность «выметания» удаленных элементов периодически в отдельную таблицу (например, RemovedItems ), чтобы минимизировать размер элементов и ускорить запросы. Но имейте в виду, что это полезно только в том случае, если вам редко нужно искать ромовированные элементы, поскольку это усложнит эти запросы (заставляя их искать в двух таблицах вместо одной). Опять же, это вопрос затрат и выгод. Один миллион строк - это не такая уж большая таблица (по крайней мере, в моем мире).