Question

I am using Ruby on Rails and devise for authentication. I have a user(customer) model and a business model. I want users(customers) to sign up through a particular business and belong to a particular business. A business has many users(customers), but a user only belongs to one business. I ended up wanting to have businesses be able to use a sub domain of their own domain to correspond to their own id, but now that I’m getting to that point I have no idea how to approach that..

Honestly I’m still in high school and I don’t have a good idea of how everything comes together with something like this. So I’m planning on licensing this app to businesses (already have a few that have paid up front before I’ve developed this thing). Each business’s data needs to be separate from the other businesses. Some businesses don’t have a domain at all so I will have to use a sub domain on my server. And some businesses do have a website so I want to use a sub domain through their business’s domain.

I’m now thinking it is definitely better to use multiple databases.. Honestly I have very limited knowledge of database structures. I believe it’s possible to run separate individual apps which I’ve been thinking may be the best way to roll this. Also maybe the easiest to develop/maintain?

So my questions are what are the tradeoffs of running multiple databases vs running separate individual apps? And where would I found out more information on how to actually do this? Also could anyone lead me into the right direction on how to forward these domain or w/e I have to do?

Also please comment if my question wasn’t clear enough… and sorry it’s so long lol.

Answer 1

Once you go down the road of multiple databases, you can’t easily go back, so you better have a very good reason for doing it. Unless you have serious scaling problems, it’s probably best to delay that decision as long as possible, and instead work on partitioning your database using standard relationships.

Rails makes it easy to do this since you can apply a scope to pretty much anything. For instance, you create a Business model, and then instead of fetching other objects directly, you always do it in a particular context. In practice this looks like:

@orders = @business.orders.paginated

You can make all of your “business-oriented” controllers descendants of a parent class that will load in the correct @business model using a before_filter so that this doesn’t have to be replicated in many different controllers.

If at any point you do want to split the databases, you can do that by separating the tables based on business_id or other derived relationships.

I’ve found this works quite well for most applications and can scale reasonably well. Remember that the first step of scaling isn’t sharing but replication, as having a number of read-only replicas can massively improve read performance without complicating your application internally.