Лучший способ сохранить пользовательские настройки?

Ответ 1

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

Ответ 2

Я справился с этим же вопросом, поэтому я решил поделиться тем, что нашел в ответе "community wiki".

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

Простые пользовательские настройки для вашего приложения Rails - это сообщение в блоге, описывающее, как это сделать.

Изменить сериализованный хеш в форме? описывает, как отредактировать такой хеш в форме. Полезный трюк заключается в том, чтобы сделать форму из хеша OpenStruct.new(@user.preferences) автоматически создавать методы доступа для каждого хэш-атрибута.

DYE/has_serialized - GitHub позволяет обрабатывать эти атрибуты в сериализованном хеше как атрибуты в (пользовательской) модели.

Предпочтения в отдельной таблице

Лучшая практика хранения пользовательских настроек? содержит несколько советов. Ниже приведены некоторые библиотеки, в том числе два из другого ответа от @hopeless.

• rails-settings управляет таблицей пар ключ/значение, такой как Хэш, хранящийся в вашей базе данных, с использованием простых методов ActiveRecord для манипуляций. Вы можете хранить любые объекты: строки, числа, массивы или любые объекты, которые можно отметить как YAML. (Протестировано с Rails 3.1 и более новыми, включая Rails 4.x и Rails 5.x)
• Preference-fu хорош для простых логических настроек, использует один столбец для нескольких предпочтений. (последнее обновление 2009 г.)
• Preferences является более гибким, использует отдельную таблицу, какой-то красивый синтаксический сахар. (последнее обновление 2011 года).
• HasEasy сохраняет данные в вертикальной таблице, но позволяет добавлять проверки, обработку до/после хранения, типы и т.д. ( Последнее обновление 2008 г.)

Вы также можете попробовать использовать метапрограммирование: Практическое метапрограммирование с помощью Ruby: сохранение настроек

Ответ 3

Улучшенная версия первого подхода может быть выполнена, если вы используете PostgreSQL 9.2/3 + и Rails 4+. Вы можете использовать store_accessor для хранения предпочтений в столбце hstore PostgreSQL с поддержкой проверок и запросов.

class User
  store_accessor :preferences, :receive_newsletter

  validates :receive_newsletter, presence: true
end

user.receive_newsletter => 'true'

User.where("preferences->'receive_newsletter' = 'true'")

Подробнее см. http://mikecoutermarsh.com/using-hstore-with-rails-4/ для дополнительной информации (миграции) и специальной заметки по обработке логических данных.

Ответ 4

Подход 2

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

Ответ 5

Есть несколько плагинов Rails для обработки этой утилиты:

• Предпочтение-fu (полезно для простых boolean preferences, использует один столбец для нескольких предпочтений)
• Preferences (более гибкий, использует отдельную таблицу, какой-то красивый синтаксический сахар)

Ответ 6

Я бы использовал 2, потому что он чище и проще обновлять. Вы сможете добавлять дополнительные настройки как можно более сложные.

Это будет немного медленнее, так как у вас есть соединение, но это будет стоить

Ответ 7

В 2016 году я вернусь Вариант 2.

Почему?

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

Подробнее