Does there exist a design-pattern for this problem?

Question

I have a big database of data which we can consider today's system. The data has a web front-end which allows my users to update the data. Let's call this "original solution"

When new users come in they come as a set of new users. These users need their own data and their own web front-end. Let's call this a "solution". Originally we have 1 solution (the original solution), however I now need the same solution for a different set of users.

Some factors that need to be considered in the design:

• The original solution may choose to implement other solutions updates and inserts on the data.
• Any solution may choose to receive updated and inserted data from the original solution.
• Updates between solutions should be easily shareable.

Now the easiest solution would be just to replicate the entire database and have some sort of process to write and read data between solutions. This however has a really high overhead when it comes to duplicate data, storage needs and so on. I would imagine storing some kind of delta between the data would be better?

I imagine a possible solution would be to design the architecture much like a source code control system with branches would be? When a new solution is implemented we branch the original solution. The different updates in branches can easily be updated into the main branch and vice-versa.

Is there any tips in how I can easily clone the data in the original solution to a new solution without replicating the actual database? Perhaps a design pattern I can use in the implementation?

Answer 1

Sounds like you are describing a multi-tenant application.

A multi-tenant application is an application that has the same code but works on different data according to the clients logged on.

Here's an article on msdn describing this in-depth: http://msdn.microsoft.com/en-us/library/aa479086.aspx

Don't mind the references to MS technology, the principles work on most major RDBM systems.

Answer 2

You could implement the command pattern to manage resp. record the actions done on the original solution, then run the same commands on the other solutions.