Rails — проблемы с наследованием одной таблицы. Любые решения / альтернативы

#ruby-on-rails #ruby-on-rails-3 #single-table-inheritance #state-machine #sti

#ruby-on-rails #ruby-on-rails-3 #single-table-inheritance #конечный автомат #sti

Вопрос:

В настоящее время для моего приложения для управления проектами я использую наследование одной таблицы, чтобы:

Вывод < Требование

Проект < Требование

Этим я хочу сказать, что руководство — это требование, а проект — это требование. Все было в порядке, пока у меня были только эти две. Затем у меня была другая подобная вещь (тендерная), поэтому я создал

Тендер < Требование

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

Из 100 потенциальных клиентов я получаю 20 проектов, а из 100 тендеров — 5 проектов.

На данный момент в качестве обходного пути я думаю, что могу использовать логическое поле, чтобы сказать, был ли это тендер. Но это сводит на нет цель создания STI. Есть ли другой способ сделать это, используя сам STI. Или это логические значения [или какое-то поле category / project_type] единственный способ добиться этого.

Могу ли я использовать state_machine для этого?

Я пытался сделать это правильно в течение некоторого времени. Любая помощь была бы отличной.

Комментарии:

1. Я использовал логические поля, и они отлично работают. Но я все еще ищу решение, которое позволит сделать это лучшим образом. Другое решение, о котором я думаю, — это has_one, но не уверен, сработает ли оно. Есть предложения?

Ответ №1:

Поскольку никто не ответил на этот вопрос, я документирую различные подходы, которые у меня есть / пытаюсь. Но по мере того, как я все больше и больше пытаюсь, мне начинает не нравиться STI.

  1. Используйте логические значения, чтобы указать, является ли требование тендером / лидом / проектом. Добавлено преимущество возможности отмечать более одного. Требование может начинаться с тендера, затем становиться лидом, а затем проектом.

  2. Поле состояния: HABTM. Можно проверить один или несколько статусов. Снова похоже на 1, но добавлено преимущество в виде возможности добавлять статусы.

  3. Есть один: но этот кажется не сухим. Не пробовал. Добавление в качестве теоретического варианта. У проекта есть одно преимущество или у проекта есть один тендер.

  4. Конечный автомат: кажется интересным вариантом. Не уверен, как я смогу отслеживать изменения состояния. Может ли кто-нибудь, имеющий опыт работы с конечным автоматом, помочь мне здесь?