Geek Answers Handbook

Rails web application: do you create a separate database for each open account?

I am going to finish creating a simple subscription-based subscription-based web application. I am setting up authorization. But since this will be my own web application that I am going to deploy, I am interested in this.

Is a separate database created for an open account?

Say you have this web application with support for support. You have ONE and ONLY ONE account holder. The account holder can set up agents that can respond to ticket support. In addition, there are customer roles that open up support tickets.

So, you can see that the database will contain users, support tickets and much more.

What is the best way?

1) Create one database for the entire application? Thus, every time someone signs up, everything is added to the same database with other tickets and user data and everything else or ...

2) Each time someone signs up, create a separate subscription subscription database.

I think option number 2 would be the best choice for data security and integrity. If so, how did you decide to tackle this problem?

+4
source share
2 answers

It looks like what you want is cartoonish:

Layering refers to the principle in software architecture, where one instance of the software runs on a server, serving several client organizations (tenants). Multiplicity contrasts with multi-instance architecture, where separate instances of software (or hardware systems) for different client organizations. With a multi-tier architecture, the software application is designed to actually break down its data and configuration, and each client organization works with a custom instance of the virtual application. - Wikipedia article on multithreading

This article, while a little dating, is a general idea about how I will deal with this. Simple Rails is multi-story . It is clean and efficient and saves you from writing code that you don't need.

+6
source

You need to choose option # 1. Number 2 (almost (there are probably cases where it’s good, but I can’t find it at the moment)) is never an option.

You are right for security reasons (well, in a way), but it also creates many other problems that you will have to think about.

  • Having a different database for each user means that for every request (remember that HTTP is stateless) you will need to open a new database connection, do everything you need to do, and then close the connection again, instead of using the connection pool. which is in Rails. This greatly affects performance.

  • Administration will be a problem, the more databases you have. In addition, having multiple databases on a server requires more resources than just a large database.

  • You will have to get around all the connection processing in Rails, as usually a single database is usually used for each application. It's easy to change the database for specific models, but it adds extra places where things can go wrong.

  • Rails has good functionality for defining areas and handling data partitioning in the same database, only for the type of use you mention.

+4
source

More articles:


All Articles