Pull to refresh
36
0
Броткин Иван @dohlik

Пользователь

Send message
Опрос проводился в Ульяновске?
Так уж прямо никто? :)
Много раз уже посмотрели? :)
Вы предлагаете сделать сноски? В принципе, интересная мысль
Возможно, не столько забрать посылку, сколько пошуметь побольше, может с кем-то из начальства повидаться.
Вас послушать, так если Apple выигрывает суд, ее продукция сразу дешевеет.
Рад за Вас :)

В чем профит? (ведь на самом деле реализовать авторизацию через OpenID/OAuth несложно, мы это знаем) Как избегаете дублированных аккаунтов и тд?
Таблицы нужны только как фундамент, чтобы описать базовые элементы. Соответственно и обсуждаем мы в основном алгоритмы, а не сами таблицы.

PS. У Вас есть предложения по логике?
Gmail ведь предупреждает о новых непонятных посещениях, но не препятствует. А мобильные браузеры отслеживаются по User-Agent, в конце концов.
А что сложного в ОпенИд-то? ))
Странное у Вас представление о семье )))
Не, ну это ж другой совсем вариант и тут все ок :) Получается, что мы выделяем некоего общего предка (общая таблица) и N детей (частные).

Другой вариант — выделение частностей в таблицу вида аккаунт_ид, ключ, значение, но это уже больше в стиле NoSQL наверное.
Про галочки я уже писал. Насчет автонаправления на логин — вероятно, так и сделаем.

Необходимость его относительная. К примеру, при привязке аккаунтов к существующему профилю можно использовать вход чере примари как подтверждение. На данный момент мы считаем это удобным, убрать несложно.
Но ведь согласитесь, что специально обрабатывать телефонные звонки — это как-то чересчур для авторизации на обычном сайте?
Авторизуйтесь на своем любом провайдере заранее, чтобы оставалось только подтвердить разрешение.
Ага. Мне сразу вспомнился пример из жизни — у нас на дипломе парень спроектировал БД для учета оргтехники. И там были отдельно таблицы для принтеров/компов/сканеров и т.д. Его хорошо помариновали вопросами на этот счет, ведь схема получается труднорасширяемая, совсем уж негибкая. Поэтому я сторонник унификации в подобных случаях.
> Если провайдеры отдают разный набор данных — то разделяем

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity