Совет по дизайну таблиц SQL

Почему вы думаете, что второй вариант будет быстрее?

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

На самом деле, это решение, вероятно, было бы быстрее, поскольку вы могли бы получить псевдоним в том же SELECT, что и другую информацию.

Обновить, чтобы ответить на вопрос об обновлении:

Вторая таблица не меньше по количеству строк. Основными факторами при поиске SQL являются 1) количество записей в таблице и 2) количество возможных совпадений из проиндексированной части поиска.

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

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

Базы данных SQL очень и очень хорошо находят данные. Правильно структурируйте свои данные и позвольте базе данных заботиться о том, чтобы вернуть их обратно. Преждевременная оптимизация — это, как говорится, корень всех зол.

Я бы оставил одну таблицу и установил уникальное ограничение для электронной почты в этой таблице.

Я не вижу ни одного преимущества в добавлении еще одной таблицы.

Выберите первый вариант: сохраните имя/никнейм в таблице участников. В этом случае нет необходимости вводить дополнительную таблицу и связанные с ней накладные расходы.

Да, связывание идентификатора участника с другими свойствами — правильный путь.

Вы можете просто создать индекс по имени, чтобы ускорить ваши запросы.