Рельсы 3. Как моделировать людей?

#ruby-on-rails #ruby #models

#ruby-on-rails #ruby #Модели

Вопрос:

У меня есть это приложение для выставления счетов.

В настоящее время у меня есть эти 4 модели:

Люди:

  • Контакты (они похожи на клиентов, им будут отправляться счета)
  • Пользователи (люди, которые отправляют счета)
  • Компания (пользователи принадлежат компании)
  • Организация (контакты принадлежат организации).

Эта текущая настройка на самом деле не срабатывает. Это не кажется естественным.

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

У людей будет столбец type_id (типы: клиент, администратор, добавим еще в будущем)

Но я не знаю, почему-то кажется, что столбец type_id не должен быть там, чтобы ссылаться только на таблицу из двух строк.

Какую настройку модели вы бы использовали в этом случае?

—- Добавлено для пояснения: —-

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

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

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

Модели

Ответ №1:

Полиморфные ассоциации могут помочь в вашей ситуации.

Поскольку все эти сущности являются людьми, вы можете реализовать что-то вроде этого:

Модель

Ответ №2:

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

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

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

1. В будущем следует добавить возможность входа клиентов (или людей, получающих счета).

2. В недавнем проекте у нас была Partner модель для хранения данных и PartnerUser < User для входа в систему.

Ответ №3:

Ваша текущая настройка не кажется мне слишком плохой.

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

Насколько важны области деятельности Компании и Организации? Могут ли контакты, которым будут отправляться счета-фактуры, просто иметь текстовое поле для названия компании и адреса? Может быть, это поможет упростить ситуацию.