ФорумРазработкаБазы данных → Тру организация полей пользователя в базе

Тру организация полей пользователя в базе

  • Ivan

    Сообщения: 1316 Репутация: N Группа: Адекваты

    Spritz 5 мая 2012 г. 21:40

    Поля допустим можно редактировать из админ панели.

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

    Первое решение, которое лезет в голову:
    columns
    id title type

    data
    id user_id column_id value


    Сразу минус: теряем типизацию данных в базе, и так как может быть text, то придется делать value большого размера

    Второе решение:
    columns
    id title type

    data_texts
    id user_id column_id value

    data_strings
    id user_id column_id value

    data_dates
    id user_id column_id value

    data_integers
    id user_id column_id value


    Но тут будет много соединений, хотя за то сохранена типизация. Можно через LEFT JOIN, можно через UNION или даже подзапросом.

    Еще вариант - в таблице users поле userdata, в формате text, и внутри XML или JSON или просто сериализованный массив со всеми данными юзера.

    Интересует следующее:
    1. Какой из этих вариантов лучше?
    2. Есть ли еще варианты?
  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 5 мая 2012 г. 21:42, спустя 2 минуты 7 секунд

    eav
  • Ivan

    Сообщения: 1316 Репутация: N Группа: Адекваты

    Spritz 5 мая 2012 г. 21:50, спустя 8 минут 2 секунды


    eav



    users_data
    id user_id attribute_id value

    attributes
    id type …


    Но тут идет минус в отсутствии типизации, потому что value может быть как числом, так и текстом
  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 5 мая 2012 г. 22:03, спустя 13 минут 24 секунды

    field_id field_type field_name
    id user_id field_id int_value string_value text_value

    ну еще option_value, можно прикрутить
  • Ivan

    Сообщения: 1316 Репутация: N Группа: Адекваты

    Spritz 5 мая 2012 г. 22:25, спустя 21 минуту 26 секунд

    Допустим нам надо получить пользователей, отсортированных в порядке даты рождения, как быть?

    SELECT *
    FROM users u
    LEFT JOIN eav_data d
    ON d.user_id = u.user_id
    LEFT JOIN eav_fields f
    ON f.field_id = d.field_id
    ORDER BY что тут писать будем?


    Или будем делать дополнительный запрос? Что-то вроде такого:

    SELECT d.date_value AS birthday 
    FROM eav_data d
    JOIN eav_fields f
    ON f.field_id = d.field_id
    WHERE f.field_name = 'birthday'
    ORDER BY d.date_value DESC
  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 5 мая 2012 г. 22:33, спустя 8 минут 15 секунд

    при eav обычно дофига джоинов, это нормально.
  • Ivan

    Сообщения: 1316 Репутация: N Группа: Адекваты

    Spritz 5 мая 2012 г. 22:41, спустя 8 минут 18 секунд

    У меня еще была такая идея:
    users_data
    id user_id … и тут список полей …


    Т.е. в таком случае в коде мы получим меньше гибкости, но это например когда мы знаем чего мы хотим.
    Редактировать поля можно будет в таком случае тоже админкой, через ALTER TABLE BLABLA, а в коде уже писать как обычно.
    Список полей для динамики можно будет выносить в отдельный XML например, и генерить той же админкой.

    За то, при таком варианте мы получим больше скорости, или я ошибаюсь?
    Просто меня пугает то, что даже самый простой запрос становится чуть ли не смертельным для базы…
  • kostyl

    Сообщения: 5210 Репутация: N Группа: Джедаи

    Spritz 6 мая 2012 г. 11:39, спустя 12 часов 57 минут 47 секунд

    Ivan, индексы проставь правильно… если у тебя там писец используй noSQL типа mongo можно заюзать
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 7 мая 2012 г. 11:47, спустя 1 день 7 минут

    MongoDb?
    Спустя 221 сек.
    Или будем делать дополнительный запрос?

    могу предложить альтернативу - компиляция в единую таблицу
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 7 мая 2012 г. 13:03, спустя 1 час 15 минут 30 секунд

    могу предложить альтернативу - компиляция в единую таблицу

    Materialized view
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • Ivan

    Сообщения: 1316 Репутация: N Группа: Адекваты

    Spritz 7 мая 2012 г. 14:20, спустя 1 час 17 минут 6 секунд


    могу предложить альтернативу - компиляция в единую таблицу

    Materialized view

    Я посмотрел, в MySQL вроде только stored procedure, это не одно и то же?
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 7 мая 2012 г. 15:11, спустя 51 минуту

    Ivan, нет, это процедуры
    в mysql есть простые вьюхи (динамические), на основе их можно переодически строить псевдо "materialized", можно и без них, но с ними красивее решение, имхо
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • phpdude

    Сообщения: 26646 Репутация: N Группа: в ухо

    Spritz 7 мая 2012 г. 15:16, спустя 5 минут 3 секунды

    adw0rd, крут))
    Сапожник без сапог
  • adw0rd

    Сообщения: 22959 Репутация: N Группа: в ухо

    Spritz 7 мая 2012 г. 15:16, спустя 39 секунд

    я бы создавал вьюху и добавлял её имя и доп. параметры (TTL, имя материализованной view) в некую служебную таблицу:

    materialized_views:
    id | view_name | ttl | materialized_view_name (default as view_name)

    далее создаешь событие, которое будет переодически делать что-то типа того:
    DROP TABLE <YOU_MATERIALIZED_VIEW>;
    CREATE TABLE <YOU_MATERIALIZED_VIEW> SELECT * FROM <YOU_VIEW>;
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • Абырвалг

    Сообщения: 6480 Репутация: N Группа: Джедаи

    Spritz 7 мая 2012 г. 15:17, спустя 35 секунд

    Materialized view

    та ну, оракл это дорого. Монго - бесплатно

Пожалуйста, авторизуйтесь, чтобы написать комментарий!