This is not a request about how to accomplish connections to multiple
databases, etc..
But, I am looking for advise on the best way to start a new project. I
will have multiple clients, each will want their data protected from
the other clients. I would probably have up to about 10 tables per
client.
The question is, in order to keep the data secure and separate, yet
have a maintainable rails app, what is the best approach to designing
the database and application workflow:
1. Create One rails app that connects to One database and creates a
new set of 10 tables per client and then put in the logic to only
allow changes and views on those 10 tables?
2. Create One rails app that connects to Multiple databases, one for
each client?
3. Create Multiple rails apps, on for each client, that each connect
to one database containing the 10 tables for the client.
Then I would use something like client1.domain.com and
client2.domain.com to tell my rails app which set of data to connect
to.
I obviously need a solution that I can maintain. Ideally would it be a
big pain to start with the one db, multiple sets of tables idea and
then migrate to one of the other options if my client list grows?
I'm assuming all 10 tables are actually the same for each client,
right? Just have an 11th table - "clients". Relate your other tables
to the clients table, and use the power of ActiveRecord to query for
all the data you need for a specific client.
You can use a before_filter in your application controller to look at
the subdomain to discover which client you're supposed to be using.
I'm assuming all 10 tables are actually the same for each client,
right? Just have an 11th table - "clients". Relate your other tables
to the clients table, and use the power of ActiveRecord to query for
all the data you need for a specific client.
You can use a before_filter in your application controller to look at
the subdomain to discover which client you're supposed to be using.
That sounds super convenient, but wouldn't it lead to really bloated
tables and slow searches in the long run? I think I would vote for
option #2, individual databases for each client. Also, obviously they
would be backed up, but this would also prevent one database getting
hosed from knocking out all your clients.