Question

We are building an a SAAS application. We need to allow customers to customize the fields of a certain model. They should be able to add or remove fields. This application is basically an asset management where customers should be able to customize the attributes of an asset.

We have tables for the assets. And these tables have multiple attribute tables like warranty, vendor, maintenance etc. i.e

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

We have default set of attributes there but a customer should be able to alter the fields.

How do we achieve this?

Ok heres what I know. For Multitenancy we can use scopes, or multiple dbs or the awesome PostgreSQL's Schemas. But how do we implement custom fields for each customer.

Should we go for NoSQL? or should we use RDBMS for base tables and NoSQL for attribute tables?

Whats the right combination or solution or architecture for a scalable SAAS app with this requirement?

Was it helpful?

Solution

It depends on use cases and you are many choices. But, in my opinion, it's better to avoid using two kinds of db together when possible.

If you are not using PostgreSQL and no heavy queries needed for those attributes, ActiveRecord serialize can help. It utilize a text field to stored serialized hash and arrays. Nesting acceptable, speed slower.

If all of the attributes are one level key/value pair, say, warranty: 18 months, vendor: 123, then "hstore" is a good choice, built-in in PostgreSQL.

"hstore" is flexible and fast, but not suitable for nested hash. And there is a great gem dealing with it: https://github.com/diogob/activerecord-postgres-hstore

If nested hash, PostgreSQL "JSON" fieldtype may help. http://www.postgresql.org/docs/devel/static/functions-json.html It's new and I havn't used that before, just heard it's more stable and practical.

I think those choices should be enough to solve your problem. If they still can't do, maybe you can consider MongoDB.

OTHER TIPS

You should definitely go for NoSQL like MongoDB. The base tables like user, profiles and other stuff which needs transaction processing should go in RDBMS.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top