Особенности хранения данных с учетом различных соц сетей

[aimatme]

Расскажите а как вы храните данные о пользователях разных социальных сетей?
сталкивался с вариантами когда все в одной таблице хранят (разделяя поиск по soctype = 'vkontakte' допустим), однако заинтересовал вариант когда основные данные хранятся в отдельной таблице, а данные из соц сети (id, имя, фамилия, адрес аватарки) в отдельных. связь между ними осуществляется за счет хранения в основной таблице soctype и socid как foreign key.

Кто как пробовал и реализовывал? как удобнее и возможно быстрее?

[Astraport]

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

[Crazy]

Сообщение от aimatme

Расскажите а как вы храните данные о пользователях разных социальных сетей?

Это зависит от того, ЗАЧЕМ вы их храните. Если, к примеру, это данные для аутентификации и пользователь однозначно определяется своей identity в выбранной социальной сети -- можно сделать как одну таблицу, так и одну общую + по одной на каждую социальную сеть с использованием общего значения первичного ключа.

Если же принадлежность к социальной сети является одним из атрибутов пользователя и допускается указание участие более чем в одной социальной сети одновременно, то однотабличная реализация явно неразумна.

[aimatme]

я вообще хочу добиться минимизации времени регистрации (занесения пользователя в базу) и минимизации времени доступа к социальным данным пользователя

то есть если использовать отдельную таблицу на данные соц сети то доступ к данным будет проходить с двумя условиями WHERE (смотрит тип соц сети и id записи в талице), а в случае с одной общей таблицей все на уровне одной таблицы c WHERE id = n
аналогично с добавлением, для того чтобы добавить пользователя мне надо записывать сразу в обе таблицы
, однако при однотабличном хранении - в одну

Насколько выигрышным будет второй вариант? (использую InnoDB)

Добавлено через 2 минуты

Сообщение от Astraport

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

имеется ввиду не идея связи между ними, а идея их хранения

[Crazy]

Коллега, Вы экономите на спичках.

[aimatme]

Сообщение от Crazy

Коллега, Вы экономите на спичках.

так все же в мелочах складывается
при 1000 запросов в час может быть выигрыш неочевиден
а при 1 000 в минуту? или в секунду?

[Crazy]

Уже при 1000 в минуту разговор начинается не с того, что храним, а с операций и их частоты. Например, если вставка новых данных происходит в 10,000 раз реже чтения и данные по каждой социальной сети запрашиваются независимо от остальных, то храним в разных таблицах. Если выборка идет по принципу "дайте все данные по социальным сетям выбранного пользователя", то вообще сериализуем все это в XML и храним в записи пользователя.

Под большой нагрузкой вообще все сильно меняется. Если Вам это всерьез не требуется -- лучше пока не заморачивайтесь, сделайте просто логически верную структуру.

[aimatme]

в том то и дело что хочу расчитать под большие нагрузки
может есть дока чтобы почитать? а то вдруг я что то не учитываю
просто хочу чтобы база не упала в самый ответственный момент при большом наплыве новых игроков (на инсертах)
а так вообще большинство операций конечно апдейты записей
поэтому использую в таких таблицах innodb который блокирует таблицу на уровне одной записи

[Crazy]

Если под большие нагрузки -- тогда идем по порядку. Вопрос первый: какие запросы (вставки, обновления, удаления, выборки) будут применяется к проектируемой структуре и какой процент обращений приходится на каждый в пиковом режиме?

P.S. Преимущественные обновления мягко говоря нехарактерны для веб-приложений (включая игры и т.п.)

[aimatme]

на одного онлайн пользователя приходится 2 селекта при логине (себя и друзей), 1 апдейт (информации из соц сети), и в среднем 2-3 апдейта (количество апдейтов в сессию не ограничено и зависит от длины сессии пользователя) и 1 инсерт под конец сессии (логи)
средняя продолжительность сессии 10 минут
если юзер новый получаем 2 допольнительных инсерта (если хранитб данные соц сетей по разным таблицам) или 1 инсерт -
итого получаем на 1 юзера: 2 селекта, 3-4 апдейта, 1 инсерт (+ 1 или 2 допольнительных)
соответственно пиковый режим наверное можно посчитать за 1000 онлайн или 2000 онлайн