Если сразу по ситуации — необходимо хранить информацию о пользователе в виде параметр-значение, но заранее не известно, сколько придется хранить информации. Это могут быть как традиционные имя-почта-пароль-статус, так и миллиард галочек рассылка-отказаться-согласиться и так далее.
Как обычно, видится два варианта:
1) Одна большая таблица с миллиардом столбцов под название каждого параметра. Из минусов — при добавлении новых колонок при увеличивающемся количестве пользователей будут фризы и вообще много гадостей. Из плюсов — сохранение и доступ в такую таблицу будут осуществляться быстро.
2) Одна таблица вида id-param, другая вида param_id — user_id — value. Из плюсов — безграничное расширение без задержек, из минусов — сложно потом контролировать этот зоопарк на чтение-запись.
Если копнуть настройки, например, твиттера, там любой из блоков (профиль, приватность и так далее) стучится на сохранение по одному адресу, условно, /profile/update, куда передается массив значений вида user[param_1], user[param_2] и так далее.
Собственно, вопрос — может быть, кто-то знает, какая магия может находиться на сервере в примере про твиттер, и какой вообще вариант можно выбрать из выше указанных двух, или, быть может, какой-то вообще третий, чтобы всё это красиво и, главное, быстро работало без сильных проблем?
Заранее спасибо и хорошего вечера понедельника всем!
А если же сортировки и выборки происходят? Предположим, одна из настроек приватности определяет, можно ли посылать пользователю оповещения, и надо выбрать всех пользователей, у которых эта настройка стоит в true?
Хранение в виде ключ-значение и неопределенность в описании структуры данных — это задачи решаемые в рамках NoSQL баз данных. Посмотрите в их сторону. Только гибкость хранения оборачивается головной болью с выборками по ключевым полям, так как судя по отзывам построение индексов там, мягко говоря, не на все случаи жизни и во многих случаях прийдется делать полный перебор по базе.
В первом варианте ничего «обычного» нет. Это вообще не вариант.
Если у нас действительно key-value хранилище, без вложенности и древовидности, то вполне подойдет второй.
Проблем с «контролем на чтение-запись» никаких не вижу. Уникальный ключ на юзер_айди-парам_айди должен решить все проблемы.
А вот если система должна поддерживать иерархию — к примеру, категория «хобби», к которой могут относиться сотни различных занятий — то как раз предложенная выше Монга и объединяет в себе эти два, на первый взгляд, противоречивые требования — хранение в JSON плюс выборки и сортировки.
Следует только учитывать особенности этой БД, являющиеся следствием её достоинств — поскольку у базы нет четкой структуры, то обязательно нужно хранить мета-информацию самостоятельно — поддерживать вручную список всех имеющихся в записях полей.
Простой
