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

Character
- Morality (may be "Good" or "Evil")
- Genre (may be "Action", "Suspense", or "Western")
- Hair Color (may be "Blond", "Brown", or "Black")

... и так далее.

Итак, для модели Character есть несколько атрибутов, в которых я хочу иметь фиксированный список возможных вариантов выбора.

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

Я могу придумать пару способов сделать это ...

1: создать строку для каждого атрибута и проверить ограниченный ввод.

В этом случае я бы определил строковый столбец «Мораль» в таблице символов, затем имел бы константу класса с указанными в ней параметрами и затем проверил ее по этой константе класса.

Поиск хороших персонажей будет какCharacter.where(:morality=>'Good').

Это красиво и просто, недостатком является то, что если я захочу добавить некоторые подробности к атрибуту, например, чтобы было описание «Добра» и «Зла», и страницу, где пользователи могли бы просматривать все символы для данной морали ,

2: создать модель для каждого атрибута

В этом случаеCharacter belongs_to Moralityбыло быMorality модель иmoralities таблица с двумя записями в ней:Morality id:1, name:Good и т.п.

Поиск хороших персонажей будет какMorality.find_by_name('Good').characters... или жеCharacter.where(:morality=> Morality.find(1).

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

3. Создание модели STI для атрибутов.

В этом случае я мог бы сделать то же самое, что и # 2, за исключением того, что создал бы общую таблицу «CharacterAttributes», а затем разделил ее на подклассы для «MoralityAttribute» и «GenreAttribute» и т. Д. Это создает только одну таблицу для многих атрибутов, в противном случае это выглядит примерно одинаково как идея № 2.

Итак, вот три способа, которыми я могу придумать, чтобы решить эту проблему.

Мой вопрос: как бы вы это реализовали и почему?

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

РЕДАКТИРОВАТЬ: По этому вопросу я добавляю награду в размере 250 (более 10% от моей репутации !!), потому что я действительно мог бы использовать более расширенное обсуждение плюсов / минусов / опций. Я буду отдавать голоса всем, кто взвешивает что-то конструктивное, и если кто-то может дать мне действительно убедительный пример того, какой подход они используют и ПОЧЕМУ это будет стоить +250.

Я действительно мучаюсь из-за дизайна этого аспекта моего приложения, и теперь пришло время его реализовать. Заранее спасибо за любую полезную дискуссию!

ЗАКЛЮЧИТЕЛЬНОЕ ПРИМЕЧАНИЕ:

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