Rails Multi Tenant SAAS-приложение с настраиваемыми пользователем полями

Question

Мы создаем приложение SAAS. Мы должны разрешить клиентам настраивать поля определенной модели. Они должны иметь возможность добавлять или удалять поля. Это приложение в основном является управлением активами, где клиенты должны иметь возможность настраивать атрибуты актива.

У нас есть столы для активов. И эти таблицы имеют несколько таблиц атрибутов, как warranty, vendor, maintenance и т.д.

т.е.

class Computer < .. 
has_one :warranty 
has_one :vendor 
end 

У нас есть набор по умолчанию атрибутов там, но клиент должен иметь возможность изменять поля.

Как мы это достигаем?

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

Должны ли мы пойти на NoSQL? или использовать RDBMS для базовых таблиц и NoSQL для таблиц атрибутов?

Какова правильная комбинация или решение или архитектура для масштабируемого приложения SAAS с этим требованием?

Answer 1

Это зависит от вариантов использования, и у вас много вариантов. Но, на мой взгляд, лучше избегать использования двух видов db вместе, когда это возможно.

Если вы не используете PostgreSQL и никаких тяжелых запросов, необходимых для этих атрибутов, ActiveRecord serialize может помочь. Он использует текстовое поле для хранения сериализованных хэшей и массивов. Вложение приемлемо, скорость медленнее.

Если все атрибуты - одна пара ключей/значений уровня, скажем, гарантия: 18 месяцев, поставщик: 123, то «hstore» - хороший выбор, встроенный в PostgreSQL.

«hstore» является гибким и быстрым, но не подходит для вложенного хэша. И есть большой камень, который имеет дело с этим: https://github.com/diogob/activerecord-postgres-hstore

Если вложенный хеш, полевой тип PostgreSQL «JSON» может помочь. http://www.postgresql.org/docs/devel/static/functions-json.html Это новое, и я раньше этого не использовал, просто слышал, что он более стабилен и практичен.

Я думаю, что этих выборов должно быть достаточно, чтобы решить вашу проблему. Если они все еще не могут этого сделать, возможно, вы можете рассмотреть MongoDB.

Answer 2

Вы должны обязательно пойти на NoSQL, как MongoDB. Базовые таблицы, такие как пользователь, профили и другие материалы, которые требуют обработки транзакций, должны поступать в СУБД.