Настраиваемые поля в Rails, которые действуют как шаблон для будущих записей

Я ищу отзывы о моем текущем плане реализации настраиваемых полей в рельсах. Я новичок в разработке рельсов и приложений в целом и буду благодарен за любые комментарии от более опытных людей.

Фон

Приложение: Следите за дегустацией еды и напитков.

Что я пытаюсь смоделировать:

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

Теперь, когда образец типа создан.

  • Пользователь начинает создавать образцы вина винного типа.
  • Они выбирают создать образец, выбирают тип вина.
  • Поля, которые они должны заполнить, - это те поля, которые они указали ранее.
  • В Origin указано: Франция, в шрифте Grape: шардоне и т. Д.

--

Мой план подхода следующий:

Когда пользователь создает образец типа, сохраните настраиваемые поля в виде массива или в каком-либо строковом формате и храните его в столбце с именем data.

SampleType
имя
вино

данные
[origin, grape_type, company, ...]

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

Образец
типа
вина

данных
{ origin: "France", grape_type: "Pinot Grigio, ... }

На данный момент я планирую использовать hstore PostgreSQL для реализации хеширования в столбце данных.

Мои вопросы:

  1. Это подходящее решение для того, что я пытаюсь сделать?
  2. Возникнут ли у меня проблемы, если пользователи изменят, какие настраиваемые поля им нужны?
  3. Есть ли другие опасения, которые мне следует принять во внимание?
  4. Является ли mongodb и другие подобные БД лучшим выбором для этого типа модели?

Я использовал следующие ссылки в качестве справочника: http://schneems.com/post/19298469372/you-got-nosql-in-my-postgres-using-hstore-in-rails http://blog.artlogic.com/ 2012/09/13 / custom-fields-in-rails /

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

Любые комментарии приветствуются.


ruby-on-rails datamodel ruby-on-rails-3 custom-fields rails-activerecord
person jtgi    schedule 20.01.2013    source источник

Ответы (1)


arrow_upward
2
arrow_downward

jtgi, я делал что-то подобное больше раз, чем мне хотелось бы вспомнить, и моей первой реакцией было "беги!" По моему опыту, вся работа с пользовательскими полями - это уродливый, хакерский кошмар. Вскоре кто-то спросит: «Можно ли поискать по винограду?» или «Я хочу иметь возможность вводить несколько значений для винограда». И так далее, и вы будете ненавидеть себя за то, что когда-либо ступили по этому пути. :-)

Тем не менее, я думаю, что ваш подход довольно приличный. Чтобы напрямую ответить на ваши вопросы:

  1. Да, это правильный подход.

  2. Да, у вас возникнут проблемы, когда пользователи изменят нужные им настраиваемые поля. (см. выше)

  3. См. Некоторые примечания ниже.

  4. Возможно. Я пошел туда еще до того, как прочитал ваш 4-й вопрос. С вашим field => value hash вы все равно реализуете решение noSQL, но реализовать поиск, поиск и т. Д. Будет нетривиально.

Некоторые мысли:

  • Я думаю, что я бы упорядочил данные в столбце db, а не использовал бы функцию db. Таким образом, это чистый Ruby и не зависит от типа db. См. http://www.ruby-doc.org/core-1.9.3/Marshal.html. Я делаю это, чтобы кэшировать некоторые данные в приложении прямо сейчас, и это довольно удобно. Вам может потребоваться маршалировать (l) данные в любом случае, если вы хотите, чтобы в итоге были сохранены объекты Ruby, более сложные, чем строки.

  • Вы, вероятно, скоро туда доберетесь, так что я бы планировал хранить некоторые «метаданные» об атрибутах, пока вы это делаете. Например, "grape" - это строка максимальной длины 20, "rating" - это целое число от 0 до 100. Таким образом вы можете сделать свою форму немного красивее и выполнить некоторую элементарную проверку.

  • Когда вы возненавидите эту особенность, вы можете вспомнить меня. :-)

person scrozier    schedule 20.01.2013
comment
scrozier, спасибо за ваш ответ. Я планировал реализовать базовую аналитику, поиск, сортировку и по этим полям, но теперь меня больше утомляет реализация. Разве нет никакого шаблона для того, чтобы делать такие вещи хорошо, похоже, что CMS придется постоянно иметь дело с такими проблемами. Я оставлю вопрос открытым еще немного, пока не приму ответ. - person jtgi; 21.01.2013