ФорумПрограммированиеPHP для идиотов → Хранение параметров пользователей

Хранение параметров пользователей

  • md5

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

    Spritz 10 октября 2007 г. 13:03, спустя 1 час 52 минуты 11 секунд

    моя точка зрения:

    * в конкретном случае мы обсуждали проектировку БД для пользователей некого портала штоли..

    вобщем я думаю, универсальное будет так: основная таблица – храним id, group_id, login, password, secret, email и ещё может пару системных полей ++ доп. таблица, в которо хранятся id_user, id_param, value, т.е. таблица где хранятся значения параметов (например рассказ о себе) + собственно таблица с именами полей, откуда мы и берём id_param

    НО!
    я очень сильный сторонник 1 варианта!
    на практике – 2 интернет-магазин, работающих по 2 разным принципам: 1 и 2.
    так вот с номером 2 – реально тяжелые запросы, реально низкая скорость по сравнению с 1.

    НО! (2)
    раз уж мы говорим об универсальности, то 2 вариант.
    очень кстати хорошо подходит для модуля вакансий в cms, где админ сам задаёт поля вакансии, ну вобщем это только пример

    НО! (3)
    Уж оооочень мне не нравится во 2 варианте хранение всех данных в текстовом формате! допустим даже выделить товар спец. предложением – это поставить галочку в админку, а в базе – это цифра 1, стоящая в огромном поле типа TEXT



    вариант 3 это ваще пздц, зачем в каждой записи хранить название параметра? О_о


    …реализация адекватна задаче…

    давайте так, внесём конкретики! проектируем БД для ПЫХА.ру
    всевидящие, уже примерно видели макет главное и ознакомлены с составом меню =)
    тогда Ваше мнение..
    все умрут, а я изумруд
  • vasa_c

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

    Spritz 11 октября 2007 г. 1:43, спустя 12 часов 40 минут 19 секунд

    Какая вам конкретика? Никакой конкретики, никакой базы для пыхи.
    Стандартная задача — система регистрации и отслеживания пользователей на универсально-среднем сайте.

    Немного изменим начальную формулировку.
    Для регистрации/авторизации и т.п. используется отдельная либа, предоставляющая какой-то интерфейс конечному программисту.
    Забудем о базах, таблицах, запросах, эффективности и т.п.
    Давайте обсудим, какой именно интерфейс хотелось бы иметь с точки зрения программиста-пользователя данной либы, да и вообще админа сайта.
    В частности, как обращаться с параметрами пользователя.
    Иметь жесткий централизованный список или нет? Какие плюсы/минусы на ваш взгляд у обоих вариантов?
  • TRIAL

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

    Spritz 11 октября 2007 г. 1:54, спустя 10 минут 24 секунды

    Сам за первый вариант.
    Ну и что, что в таблице будут поля которые юзер не заполняет. Нам то что?!? Места они не занимают, база от пустых строк тяжелее не будет. Ну если конечно там на сотня полей. Хотя и тут поспорить можно.
    Кстати представь что тебе надо срочно изменить тип столбца в таблице а у тебя уже 1000 пользователей и для каждого своя таблица с данными и ты вынужден будешь во всех этих таблицах менять тип.
    Хотя у меня глобальный проект есть на миллион пользователей как минимум и какую структуру выбрать тут фиг знает. Если одна таблица то это всё, пзц полный будет.
    from TRIAL with LOVE
  • vasa_c

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

    Spritz 11 октября 2007 г. 2:08, спустя 14 минут 1 секунду

    1000 пользователей и для каждого своя таблица с данными

    По-моему ты не совсем точно разобрался в предложенных вариантах :)
  • Dagdamor

    Сообщения: 47 Репутация: N Группа: Кто попало

    Spritz 11 октября 2007 г. 2:21, спустя 13 минут 5 секунд

    speedleader
    Этот вариант здесь не годится - новые темы создаются постоянно и без участия разработчиков проекта. Понятно, что в таком случае "горизонтальный" вариант не подходит. Но я говорил о полях наподобие профайла пользователя (как я понял, изначально об этом был разговор)… т.е. такие поля, количество и типы которых сами посетители изменить не могут.

    vasa_c
    В принципе, если рассмотреть такую гипотетическую задачу - "очень много полей, очень мало фактических данных", то первый вариант действительно не подходит. Особенно если перейти к предельному случаю, когда количество и типы полей вообще заранее неизвестно, а реальных данных в базе кот наплакал. Если у вас именно такой случай - да, придется воспользоваться вторым вариантом. Но он мне все равно не нравится…
  • Dagdamor

    Сообщения: 47 Репутация: N Группа: Кто попало

    Spritz 11 октября 2007 г. 2:23, спустя 2 минуты 12 секунд

    vasa_c
    Забудем о базах, таблицах, запросах, эффективности и т.п.
    Давайте обсудим, какой именно интерфейс хотелось бы иметь с точки зрения программиста-пользователя данной либы, да и вообще админа сайта.

    Он пытается придумать универсальное решение! На костер его! :)))
  • vasa_c

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

    Spritz 11 октября 2007 г. 2:30, спустя 6 минут 45 секунд

    Не вообще универсально.
    Вот ты делаешь свой PHPC, ты же не делаешь его сверхуниверсальным. Но учитываешь, что он будет стоять на различных сайтах, и параметры пользователей там могут быть разные. Или ты жестко зашил эти параметры в базу и теперь на каждом сайте одно и то же? Извини, разобраться в твоих исходниках пока не было времени :)
  • Dagdamor

    Сообщения: 47 Репутация: N Группа: Кто попало

    Spritz 11 октября 2007 г. 2:49, спустя 19 минут 4 секунды

    vasa_c
    Это шутка была :)
    На всех сайтах на PHPC, где нужна была регистрация/авторизация, я делал первый вариант. Управлять набором полей профайла можно, но только админу из админки. При добавлении нового поля в профайл добавлялось новое поле в таблицу пользователей + добавлялась запись в таблицу userfields, где можно было для этого поля указать название, примечание, тип, порядок следования, обязательное или нет, заполняется при регистрации или нет и прочее. Т.е. универсальность есть, но ограниченная.

    Для меня все параметры пользователей делятся на 2 группы - те, которыми сам пользователь может управлять, и те, которыми он не может. Первое - это поля профайла. Второе - права. И в том и в другом случае можно сделать "горизонтальное" решение. И если сильно не чудить, получится очень даже красивая, быстрая и надежная реализация…
  • TRIAL

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

    Spritz 11 октября 2007 г. 2:59, спустя 10 минут 38 секунд


    1000 пользователей и для каждого своя таблица с данными

    По-моему ты не совсем точно разобрался в предложенных вариантах :)

    Ой блин и правда стормознул ))) Всё, дошло ))) ну впринцыпе да, с одной стороны удобно и нормально, но с другой по большому счету та же фигня что и хранение всего этого в одной
    from TRIAL with LOVE
  • vasa_c

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

    Spritz 13 октября 2007 г. 0:30, спустя 1 день 21 час 30 минут

    Попробуем подойти к вопросу с несколько другой стороны.

    Кроме "профильных" параметров с пользователем приходится связывать некоторые другие данные.

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

    Например, админка — раздел "новости". На странице идет таблица "список новостей", под ней форма "добавить новую новость".
    1. Я хочу иметь возможность настраивать таблицу — количество новостей на одной странице, упорядочивание по какому-то столбцу и т.п.
    2. Я хочу иметь возможность переключать вид страницы "показывать список и форму" - "только форму" - "только список".
    3. Я хочу, чтобы когда я в следующий раз сюда приду, все настройки были бы сохранены.
    И таких страниц тьма.
    Как сохранять такие параметры (понятно, что не в куках и не в сессиях)? Централизовано хранить нееб.ческое количество вариантов? Если все же "да", то как изначальное ядро будет знать о структуре модулей?

    Вариант раз — свалить это всё на плечи каждого конкретного кода. Есть сценарий отвечающий за страницу с новостями, пусть он и сохраняет настройки где хочет. Но это полный крандец.
    Вариант два — сделать что-то вроде переменных, привязанных к пользователю. Интерфейс сделать в виде функций (или методов каких-то классов):

    setUserVar('newsTableOrder', 10); // Установили переменную "newsTableOrder" для текущего авторизованного пользователя.
    getUserVar('newsTableOrder'); // Получили значение переменной

    Собственно, интерпретация переменных остается, конечно, в ведении конкретного сценария, но ядро системы предоставляет удобные средства для их хранения и получения.


    Вопрос номер раз — сталкиваетесь ли вы с подобными вещами и, если да, то как их решаете?

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


    Вернемся к профилю

    В модульной системе, кроме фиксированного набора полей профиля, общего для всех пользователей, могут быть поля, специфические для каждого модуля.
    Есть сайт, на нем есть новости (за которые отвечает модуль новостей). Среди зарегистрированных пользователей, есть, допустим, редакторы новостей, которым дозволено оставлять новости. И есть специфические поля профиля, относящиеся именно к редакторам. При этом:
    1. Из миллиона зарегистрированных пользователей, редакторов десять штук.
    2. Ядро движка модульного сайта, понятия не имеет какие модули с какой структурой к нему подключены.

    Получение, хранение, обработку и вывод данных параметров можно опять таки полностью свалить на каждый конкретный модуль. Только так не интересно.

    Вопрос номер три — как решает эти проблемы тот, кто с ними сталкивался?


    Ну и не буду дальше растекаться мыслью по древу:

    Вопрос номер четыре — стоит ли разделять на программном уровне "общий профиль", "специфические профильные данные" и "внепрофильные данные"?
    Вот есть у нас setUserVar() и getUserVar(), чего нам еще не хватает для того, чтобы организовать хранение и выдачу данных профиля?

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