Если вы хотите, чтобы это решение масштабировалось вообще, вы должны не пытаться извлечь подколонки. Функции для каждой строки известны своей медлительностью, поскольку таблица становится все больше и больше.
В этом случае правильное нужно сделать, чтобы переместить стоимость извлечения с select (где это часто происходит) на insert/update, где это происходит меньше (в большинстве обычных баз данных). Взяв на себя расходы только на insert и update, вы значительно увеличите общую эффективность базы данных, поскольку это только момент времени, когда вам нужно это сделать (т.е. это единственный раз, когда при изменении данных).
Чтобы добиться этого, разделите адрес электронной почты на два отдельных столбца в таблице, email_user и email_domain). Затем вы можете либо разделить его в своем приложении перед вставкой / обновлением, либо использовать триггер (или предварительно вычисленные столбцы, если ваша СУБД поддерживает это) в базе данных, чтобы сделать это автоматически.
Затем вы сортируете по email_domain и, когда вам нужен полный адрес электронной почты, вы используете email_name|'@'|email_domain.
Кроме того, вы можете сохранить полный столбец email и использовать триггер для дублирования только части домена в email_domain, тогда вам не нужно беспокоиться о объединении столбцов для получения полного адреса электронной почты.
Вполне допустимо вернуться из 3NF по соображениям производительности, если вы знаете, что делаете. В этом случае данные в двух столбцах не могут быть синхронизированы просто потому, что триггеры этого не допустят. Это хороший способ обменять дисковое пространство (относительно дешево) на производительность (мы всегда хотим большего).
И, если вы совсем не любите возвращаться из 3NF, решение email_name/email_domain исправит это.
Это также предполагает, что вы просто хотите обрабатывать адреса электронной почты в форме a@b - есть другие действительные адреса электронной почты, но я не могу вспомнить, чтобы кто-нибудь видел их в дикой природе в течение многих лет.