как хранить / моделировать пользователей / пользователей facebook / пользователей linkedin и т. д. с помощью ActiveRecord?

Question

В моем приложении

• "обычные" пользователи: те, которые заходят на обычную страницу регистрации
• пользователей Facebook (FB): те, которые приходят с Facebook, подключаются
• "FB-normal" пользователи: пользователь, который может войти с электронной почтой или паролем * FB connect

Кроме того, существует множество других методов входа в систему openID (я не думаю, что сам openID будет приемлем, поскольку он не связывает учетные записи и не позволяет сторонним функциям (публикация в твиттере, добавление ФБ пост и тд и тп))

Итак, как мне смоделировать это?

Прямо сейчас у нас есть класс User с #facebook_user? определены - но это становится беспорядочным с "нормальными" пользователями FB - плюс все проверки становятся очень хитрыми и трудными для интерпретации. Также есть такие методы, как #deliver_password_reset! которые не имеют смысла в контексте только для пользователей Facebook. (это хромает)

Я продумал STI (пользователь :: Facebook, пользователь :: нормальный, пользователь :: FBNormal и т. Д.). Это делает проверки супер гладкими, но не масштабируется для других типов соединений. и все перестановки между ними ... User :: FacebookLinkedInNormal (wtf?) Делать это с кучей модулей, я думаю, было бы много.

Есть еще идеи?

Answer 1

Я бы разделил проблемы, кажется, что не имеет смысла хранить записи, которые имеют совершенно разные поля в одной таблице.

Просто имейте одну пользовательскую модель / таблицу, которая не сохраняет никаких учетных данных, и сделайте так, чтобы иметь отношение has_many к методу Account / Login, где вы можете использовать STI для моделирования различных типов.

class User < AR::B
  has_many :accounts
end

class Account < AR::B;end

class PasswordAccount < Account;end 

class GoogleAccount < Account;end

class FacebookAccount < Account;end

…

Answer 2

Вы столкнулись с одним из этих несоответствий объектно-реляционного импеданса наземных мин.

Facebook и LinkedIn решают эту проблему с помощью нереляционных хранилищ ключей / значений. Facebook использует Cassandra , а LinkedIn использует Project Voldemort .

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

В СУБД я разработал бы это, используя Наследование таблиц классов .