Использование пользовательских полей столбца вместо EAV
Я нахожусь в процессе создания приложения, которое, помимо прочего, также имеет раздел управления информацией о пользователях. Существует 10 основных полей, которые пользователи заполняют для регистрации (имя, фамилия, адрес и т. Д.), Но администратор также может определить настраиваемые поля, которые будут включены в регистрационную форму.
На данный момент я реализовал это с EAV. У меня есть стол «пользователи» который содержит все 10 основных полей в виде столбцов, users_custom_fields (field_id, field_name, field_type), который содержит все пользовательские поля и таблицу «users_custom_data» (user_id, field_id, field_value), который содержит все данные для пользовательских полей.
Мой вопрос заключается в следующем: не было бы лучше, если бы добавление нового поля в бэкэнд php просто создавало новый столбец в таблице «users» вместо создания отношения «один ко многим», где каждая запись пользователя также совпадает с несколькими строки в «user_custom_data», что делает его действительно трудным для поиска и добавляет ненужную сложность?
Считается ли это плохой практикой, если приложение динамически изменяет структуру таблицы?
Спасибо
Решение
«Считается ли это плохой практикой, если приложение динамически изменяет структуру таблицы?»
По моему опыту, да. Тем не менее, вы столкнулись с одним местом, я думаю, что это может есть место. Но вы должны выяснить, как справиться с парой вопросов, которые это поднимает …
Где хранится отображаемое имя поля? Что будет отслеживать эти новые поля? так далее…
Вы могли бы дать каждому такому полю стандартный префикс какого-то рода, скрытый для пользователя, создавшего их, и использовать информационную схему для «поиска» полей во время выполнения; но вам все равно придется иметь дело с именами, которые могут быть не дружественными к SQL, или что делать, если пользователь хочет, чтобы значения ограничивались целыми числами, а не какой-либо допустимой строкой. Все это можно решить, создав дополнительную таблицу для хранения метаданных, но затем вы начнете (в большинстве случаев) делать лечение (для EAV) хуже, чем болезнь.
Редактировать: я бы почти раньше дал «администраторам» пользователей ограниченные интерфейсы для создания дополнительных таблиц для этих вещей, а не столбцов в основных таблицах.
Другие решения
Других решений пока нет …