Насколько эффективная такая схема работы и как ее улучшить?

Question

[Денис]

Насколько эффективно хранить данные о пользователях в MySQL по принципу key-value?
То есть есть у пользователя ряд «характеристик», которые задаются изначально при регистрации (к примеру, имя, фамилия, год рождения).

id user_id field_type field_val
1 1 name ivan
2 1 firstname ivanov
3 1 byear 1989

Есть форма на сайте с этими и другими полями.
Пользователь заполняет те поля, которые желает.

1) Возможно часть полей, которые ранее были заполнены — теперь пусты, и нужно либо удалить их из базы, либо обнулить.
2) Возможно часть полей, ранее были НЕ заполнены — и их нужно внести в БД.
3) Часть полей были изменены и их значения нужно изменить в БД.

Какой алгоритм обновления данных пользователя лучше применить?

Answer 1

[victimofbrainlessness]

Вне всякого сомнения EAV штука полезная. Но стоит задуматься о целесообразности перевода обсолютно всех характеристик в EAV. На примере той же даты рождения: в EAV значения атрибутов будут либо все строковые, либо бинарные, как отследить всех тех кто родился в СССР? на лету конвертирывать данные в DATE и потом делать отбор? А как делать выборку по числовым значениям, сортировку? Все же стоит набор основных характеристик оставить в обычном строковом представлении.

Обновление данных вообще геморой.
1. Считать все строки совподающие по user_id (сохранить данные в сессию)
2. Распечатать форму
3. Построково сверить данные из сессии с данными из формы.
3.а. новые атрибуты (нет данных в сессии/дб) агрегирывать и вставлять одним запросом
3.б. обнуленные атрибуты агрегирывать и либо удалять, либо апдейтить в эмпти стринг по желанию
3.в. изменные построково апдейт.

может стоит посотреть в сторону NoSQL/schemaless?
были посты на хабре, сфинкс вам в помощ

Answer 2

[Павел Загребелин]

Неудобно будет, что числа (год рождения), даты (дата регистрации) и строки (firstname) хранятся в одной колонке, и всякие фильтрации по годам придётся вести как со строками.

Answer 3

[koriaf]

Не думаю что в таком усложнении системы будет какой-то выигрыш. В mysql.

Answer 4

[Николай Васильчук]

Если у вас фиксированное количество полей, зачем изобретать велосипед — храните всё в одной таблице (user_id, name, birthday, field_1,… field_N).
Если поля добавляются (из админки сайта, например, если это сайт), то лучше создавайте каждому типу поля (int, text, date, etc) новую таблицу.
В друпале, например, вообще каждому новому полю создается своя таблица, а в запросах потом куча JOIN'ов.