Разработка STI против MTI против отдельных таблиц

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

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

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

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

Мысль?


person Joel Jackson    schedule 14.08.2011    source источник


Ответы (1)


Лично я не думаю, что неиспользуемые столбцы так уж важны, однако, если это вас действительно беспокоит, вы можете попробовать неортодоксальное решение. Рассматривали ли вы возможность «группировать» все атрибуты, которые не являются общими для разных типов пользователей? Я говорю об использовании плагина, такого как 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. Когда вы снова загрузите модель, они будут прозрачно десериализованы.

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

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

person skorks    schedule 14.08.2011
comment
Никогда не сталкивайтесь с таким подходом раньше. Я посмотрю на наши требования и посмотрю, подходит ли он. Спасибо! - person Joel Jackson; 19.08.2011