August 16, 2005 at 2:53 am
We are developing a web based employee performance tracking application. A company that needs our services subscribes to us and we allow the company to use our portal for tracking the performance of its employees.
Lets say we have 10 companies as our customer. We have adotped the following approach
"We have a main DB for storing companies information. We create and store a single subscriber company details on new a DB and that new DB is enlisted in main DB. Similarly, for every new company we create an entire new DB. The schema (tables/ sps / views) of all the customer database are exactly same. They differ only by data. This approach was adopted mainly for performance."
Biggest problem with this approach is its resistability to changes. If i need to change an SP in one customer DB i've to mirror that change manually in all the other customer DBs.
Is it preferred approach for doing this? Another approach is use of federated databases but i'm even not too sure about that....
Is there any other alternative ??
Thanks in advance....
August 18, 2005 at 3:00 pm
It looks like your application may be a little more complex than you can explain in a post.
Hence it will be difficult for us to provide you with an answer.
It is good that you are asking questions.
Each solution has cost and benefit. And each way you go will add complexity to your application.
In my opinion it will be very challenging to implement tons of new databases. And you can partition your tables, across many disk drives without using federated database servers. But your transactions per minute threshold may be so that you are required to use federated servers. No way to answer this.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply