Разработайте ИППП против МТИ против отдельных таблиц - PullRequest
Новая
       6

Разработайте ИППП против МТИ против отдельных таблиц

1 голос
/ 14 августа 2011

У меня есть проект rails 3.1, использующий devise для аутентификации.

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

Должен ли я оставить их все как отдельные таблицы или перенести их в одну таблицу?Наследование нескольких таблиц не имеет особого смысла, учитывая тот факт, что мы будем постоянно искать пользователей.Это было бы слишком дорого с точки зрения объединения.

Просто очень грязно иметь в таблице все неиспользуемые столбцы для каждого типа пользователя.

1 Ответ

1 голос
/ 14 августа 2011

Лично я не думаю, что неиспользуемые столбцы имеют большое значение, однако, если это действительно беспокоит вас, вы можете попробовать неортодоксальное решение.Рассматривали ли вы «группирование» всех атрибутов, которые не являются общими для ваших разных типов пользователей?Я говорю об использовании такого плагина, как attr_bucket .

По сути, вы бы добавили дополнительный столбец в свою таблицу базы данных: 

t.text :non_common_attributes

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

class UserType1 < User
  attr_bucket :non_common_attributes => [:first, :second, :third]
end

class UserType2 < User
  attr_bucket :non_common_attributes => [:fourth, :fifth]
end

Вы бы использовали атрибуты так же, как они были определены обычным способом, но при сохранении модели в базе данных все эти атрибуты будут сериализованы через YAML и сохранены в столбце :non_common_attributes.Когда вы снова загрузите модель, они будут прозрачно десериализованы.

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

Infact, Iиспользовали аналогичное решение (но не с использованием драгоценных камней), а с моделью, в которой большинство атрибутов необходимо зашифровать.Я просто собираю все атрибуты вместе и зашифровываю корзину - работает удовольствие.

...