Recursion series | Problem BunnyEars | CodingBat | Java | Understand Rec...

Count the number of Duplicates | String | Leetcode | Data Structure | Al...

Explained Recursion in a simple way | Factorial of Number | Java | Probl...

Count the number of Set bits in an Integer/decimal number | Java | interview question

public class SetBits {

public static void main(String[] args) {
// how to find number of set bits in Decimal number
// means number of 1's present in decimal number


int num = 5 ;
int count = 0;
// 8 bits representation of 5 : 00001001

while(num>0) {

if((num & 1) == 1) {
count++;
}

num=num>>1;
}




System.out.println(count);
}
}


Output : 2

Youtube video link:
https://youtu.be/Jh9i1OLLfks

1410. HTML Entity Parser | LeetCode | Linear time complexity | JAVA

130. Surrounded Regions | LeetCode | BFS | DFS | Data structure and Algo...

HashMap sort by values | Collections.sort | Interview Question | Leetcod...

Search in a Binary Search Tree | Recursive | Leetcode | Datastructure an...

LEETCODE: Search in a Binary Search Tree | Datastructure and Algorithms ...

How to create Immutable class | use of final keyword | Java | Interview ...

Find the Pair with given sum in the array | count the Pairs | Data struc...

Binary array sort in linear time and constant space (O(n)) | Data struct...

String substring method internal implementation | String class | JAVA | ...

HashMap sorting by its values | Collections.sort | JAVA | Sorting | Comp...

Problems : When we create a database per customer?

This solution is called a multi-tenant design where each tenant (customer) has their own database. Given that, there are some other considerations to the alternative approach which is a single database:

1. With a single database, everyone must be on the same version no matter what. It isn't possible to upgrade some customers and not others. This can be problematic if a customer wants a hotfix of an application that isn't ready for wide release.
2. With a single database, when you do an upgrade, every client is down. If something goes wrong, every client is screwed.
3. With a single database, it is much more difficult to throttle resources. I.e., if one client is hammering the database, it is harder to give them more resources separate from everyone else.
4. It is much more difficult to allow users to host their own versions of your application. If you are building a solution that will be used by large enterprises, this is often a non-starter. Their IT department wants complete control over access to the system.
5. It is probably cheaper to scale out databases rather than scale them up. I.e., having to invest in faster hardware to host one database to rule them all is probably more expensive than being able to scale customers out to smaller, less expensive database servers. I can't say this one definitively because it depends greatly on the server software. If you stick with MySQL, this is probably true because the licensing costs are negligible. However, if you move up to SQL Server for example, scaling out becomes much more expensive unless you use a VPS environment and the cost-benefit of scaling up vs. scaling out changes. I can say, however, that once your database gets very large, management requires ever-greater levels of expertise. Very large databases require playing around with multiple filegroups and pushing certain indexes to different spindles to get better performance. In short, they get can complicated very quickly.

Having separate databases does mean you have to build an update mechanism which matches the database version with the application/site version. However, separate databases do provide superior isolation of data and IMO have a lower cost of hosting. It isn't a solution for all scenarios. If your system were never going to be hosted outside of your hosting and needed to scale up in customers rapidly and having all users on the same version of the application and database schema was desirable, then certainly having a single database is a better approach.

Some separate Points Pros and cons:

Advantages of a database per customer

• Simpler database schema
• Simpler backups - you can backup each customer in turn without it really impacting on other customers.
• Makes it easy to export a given customers data.
• Better cache performance - a write to one of the more active tables only impacts that single customer that performed the write.
• Easier to scale across hardware. For example, when we need to go from 1 to 2 servers, we just move half our customers to the new server.

Disadvantages

• Can MySQL cope with 5,000 databases? Would performance suck?
• Changes to the schema can be hard to replicate out across all the databases. We would really really have to have an automated plan for this, such as versioning the schema and a script that understands how to take a database from one version to another.
• Doing anything that is common to all our customers might be awkward or impossible
• Similar to above, but any analytics we want to perform across all our customers might be impossible. How should we track usage across all customers for example?